Default Drop with an Allow Any to Any

Bart, 

When posting a line from the firewall log, use the line from the full Firewall log file.  Unlike the other Live Logs, the Firewall Live Log omits the details needed to analyze a problem.

Cheers - Bob

Hello Bob,

Sorry for the late respons, but here's the detailed log:

fwrule="60001" initf="eth0" srcmac="00:0c:29:32:69:12" dstmac="00:1a:8c:f0:66:e0" proto="17" length="360" srcip="***x:***x:***x:cd05:2000::5" dstip="***x:***x:***x:cd05:2000::11" hlim="64" srcport="10952" dstport="500" 
2015:05:30-00:47:22 fw2-2 ulogd[6828]: id="2001" severity="info" sys="SecureNet" sub="packetfilter" name="Packet dropped" action="drop" fwrule="60001" initf="eth0" srcmac="00:0c:29:32:69:12" dstmac="00:1a:8c:f0:66:e0" proto="17" length="360" srcip="***x:***x:***x:cd05:2000::5" dstip="***x:***x:***x:cd05:2000::11" hlim="64" srcport="10952" dstport="500" 
2015:05:30-00:47:27 fw2-2 ulogd[6828]: id="2001" severity="info" sys="SecureNet" sub="packetfilter" name="Packet dropped" action="drop" fwrule="60001" initf="eth0" srcmac="00:0c:29:32:69:12" dstmac="00:1a:8c:f0:66:e0" proto="17" length="360" srcip="***x:***x:***x:cd05:2000::5" dstip="***x:***x:***x:cd05:2000::11" hlim="64" srcport="10952" dstport="500" 
2015:05:30-00:47:33 fw2-2 ulogd[6828]: id="2001" severity="info" sys="SecureNet" sub="packetfilter" name="Packet dropped" action="drop" fwrule="60001" initf="eth0" srcmac="00:0c:29:32:69:12" dstmac="00:1a:8c:f0:66:e0" proto="17" length="360" srcip="***x:***x:***x:cd05:2000::5" dstip="***x:***x:***x:cd05:2000::11" hlim="64" srcport="10952" dstport="500" 
2015:05:30-00:47:40 fw2-2 ulogd[6828]: id="2001" severity="info" sys="SecureNet" sub="packetfilter" name="Packet dropped" action="drop" fwrule="60001" initf="eth0" srcmac="00:0c:29:32:69:12" dstmac="00:1a:8c:f0:66:e0" proto="17" length="104" srcip="***x:***x:***x:cd05:2000::5" dstip="***x:***x:***x:cd05:2000::11" hlim="64" srcport="10952" dstport="500" 

Fun part:
I've I add an IPv4 adres to the WAN interface, I can build up an IPSec tunnel.

Bart, one of the exciting things about IPv6 is that all traffic is encrypted, so there's no reason to use an IPsec client with it.  I would have been surprised if Sophos had made IPsec compatible with IPv6.

Cheers - Bob

Bart, one of the exciting things about IPv6 is that all traffic is encrypted, so there's no reason to use an IPsec client with it.  I would have been surprised if Sophos had made IPsec compatible with IPv6.

Cheers - Bob

Sorry, but not all IPv6 traffic is encrypted. IPsec is an integral part of IPv6 in the sense that all compliant IPv6 implementations must support IPsec. They are not required to encrypt all communications using IPsec, and they don't. 

I just sniffed example IPv6 traffic just to confirm the correctness of my statements above, and I saw readable plaintext. I also sniffed ping6 datagrams. Note: If you repeat my experiment and want to see readable plaintext, keep in mind that you must find IPv6 websites that are not using compression, HTTPS, etc. Try this one: 
  What is my IPv6 Address?


For ping6 testing, I used: 
  ping6 -s 512 -p ff ipv6.google.com
  ping6 -s 512 -p a0 ipv6.google.com

Interesting.  I knew that they had changed "must support IPsec" to "should" several years ago, but I didn't realize that any production IPv6 environment was unencrypted.  If you go to the google.com IPv6 address, 2607:f8b0:4000:806::1005, do you see that the traffic is not encrypted?

Cheers - Bob

Interesting.  I knew that they had changed "must support IPsec" to "should" several years ago, but I didn't realize that any production IPv6 environment was unencrypted.  If you go to the google.com IPv6 address, 2607:f8b0:4000:806::1005, do you see that the traffic is not encrypted?

Cheers - Bob

Funny, but my browsers did not like the raw IPv6 address in the address bar. They did a web search for "2607:f8b0:4000:806::1005" instead. :-)

Next I tried forcing an "http://" in front of the IPv6 address, but got a blank screen - something wasn't right.

I assume that the IPv6 address is "ipv6.google.com", but it does not match my host DNS lookup, which is: 2607:f8b0:4009:804::1004

Next I put "ipv6.google.com" in the browser and it worked. I saw a small amount of http traffic, the redirection to https. After that, I could see the TLS protocol contents going back and forth in "plaintext" (no IPsec), but of course the contents were encrypted by the higher level TLS protocol, not IPsec. The browser icon in the address bar changed to indicate "https".

Does that answer your question?

Bart, one of the exciting things about IPv6 is that all traffic is encrypted, so there's no reason to use an IPsec client with it.  I would have been surprised if Sophos had made IPsec compatible with IPv6.

Cheers - Bob

Hi Bob,

According to this website:
https://blogs.sophos.com/2013/12/04/sophos-ipsec-client-v10-32-released/

The Sophos IPSec Client has IPv6 support. 
But if the client is IPv6 ready or not, why is port 500 blocked on the WAN interface of the UTM?

The reason I use a IPSec tunnel is for administrators to make a connection to the inside Management LAN (Remote Access, the total LAN structure is IPv4).

Utmadm, you have a Windows 7 PC that is using IPv6, you've configured Windows Firewall to use IPsec with IPv6, you have no masq or NAT rule for the traffic from your PC to the Internet, you are sniffing the traffic at the UTM and it is not encrypted?

Bart, your firewall rule doesn't apply to traffic in the INPUT chain (see the attachment in Rulz).  It appears that the IPsec server doesn't yet support IPv6 or maybe there's a configuration issue.  I like to use the same technique for access to WebAdmin - adding "Bart (User Network)" to 'Allowed networks' in 'WebAdmin Settings'.

Cheers - Bob

Utmadm, you have a Windows 7 PC that is using IPv6, you've configured Windows Firewall to use IPsec with IPv6, you have no masq or NAT rule for the traffic from your PC to the Internet, you are sniffing the traffic at the UTM and it is not encrypted/

Bart, your firewall rule doesn't apply to traffic in the INPUT chain (see the attachment in Rulz).  It appears that the IPsec server doesn't yet support IPv6 or maybe there's a configuration issue.  I like to use the same technique for access to WebAdmin - adding "Bart (User Network)" to 'Allowed networks' in 'WebAdmin Settings'.

Cheers - Bob

Hi Bob,

No. I have a Mac running OS X 10.9.5 (Mavericks) that is has a fixed "Manual" IPv4 address and IPv6 enabled in Advanced->Configure IPv6 to "Automatically". It uses the standard OS X application level firewall with none of the options checked, and with an assortment of applications configured for Allow or Block as appropriate.

There is an Internal to External NAT rule on the UTM. The NAT rule appears to apply to the IPv4 10-net (a /24) and the IPv6 network (a /64), which I see when I edit the NAT rule and hover the mouse over the "Network" entry. All internal IPv4 addresses are on the private 10-net. Most systems have fixed IPv4 addresses and automatic IPv6 addresses as described above. 

The UTM is the DHCP server for the IPv4 10-net, the only DHCP server. I did not create an IPv6 DHCP server on the UTM. 

I created masquerade rules on the UTM that redirect input on randomly chosen ports to local ports on certain systems for remote connections to those systems. (Someday, I will replace it with VPN access.) I doubt these have anything to do with it.

I sniffed the packets using Wireshark on the same Mac that performed the various network actions. 

I hope this helps. 

Cheers,

utmadm

Hmm, I wonder if the UTM's IPv6 implementation is not yet capable of negotiating IPsec.  Can anyone comment on that?

Utmadm, I think you would have to setup your Mac to negotiate IPsec in order to see encryption on it.  If the UTM is doing it, then you would have to sniff at its external interface.

Cheers - Bob