1
19.7 Legacy Series / reply-to in WAN firewall rules seems to break inbound IPv6 connections
« on: November 11, 2019, 12:38:12 am »
I'm running into a weird issue where IPv4 WAN connections to a service on the firewall work, but IPv6 WAN connections don't. A tcpdump capture shows that the packets are making it to the firewall, but the replies are not making it back to the client.
I first noticed this with OpenVPN, but for ease of testing, I just added a temporary rule to allow IPv4/IPv6 TCP port 22 connections from the WAN interface. These are the rules that get created in /tmp/rules.debug:
With this rule in place, I can SSH to the firewall on IPv4, but not IPv6. I noticed the reply-to IPs in the rules and double checked that they matched the default gateways on the firewall:
I tested to make sure these default gateways work by curling https://www.example.com on both IPv4 and IPv6:
Just for the heck of it, I modified the rule to disable reply-to and surprisingly, that allows the SSH connection over IPv6 on WAN to work.
While the workaround does the job, I'm not really understanding why the reply-to is breaking the IPv6 connection. I only have a single WAN connection and it seems that the gateways are set up properly. What else might possibly cause this issue? I'd appreciate any insight into this!
My setup:
I first noticed this with OpenVPN, but for ease of testing, I just added a temporary rule to allow IPv4/IPv6 TCP port 22 connections from the WAN interface. These are the rules that get created in /tmp/rules.debug:
Code: [Select]
pass in log quick on em0 reply-to ( em0 174.100.64.1 ) inet proto tcp from {any} to {(self)} port {22} keep state label "c82dc16f4641fbf2db9fffa867fb1332" # : TEST2
pass in log quick on em0 reply-to ( em0 fe80::201:5cff:fe8d:9c46 ) inet6 proto tcp from {any} to {(self)} port {22} keep state label "c82dc16f4641fbf2db9fffa867fb1332" # : TEST2
With this rule in place, I can SSH to the firewall on IPv4, but not IPv6. I noticed the reply-to IPs in the rules and double checked that they matched the default gateways on the firewall:
Code: [Select]
root@opnsense:/home/chenxiaolong # netstat -nr | grep default
default 174.100.64.1 UGS em0
default fe80::201:5cff:fe8d:9c46%em0 UG em0
I tested to make sure these default gateways work by curling https://www.example.com on both IPv4 and IPv6:
Code: [Select]
root@opnsense:/home/chenxiaolong # curl --fail -4 https://www.example.com -o /dev/null -sS; echo $?
0
root@opnsense:/home/chenxiaolong # curl --fail -6 https://www.example.com -o /dev/null -sS; echo $?
0
Just for the heck of it, I modified the rule to disable reply-to and surprisingly, that allows the SSH connection over IPv6 on WAN to work.
While the workaround does the job, I'm not really understanding why the reply-to is breaking the IPv6 connection. I only have a single WAN connection and it seems that the gateways are set up properly. What else might possibly cause this issue? I'd appreciate any insight into this!
My setup:
- The firewall is running OPNsense 19.7.6-amd64
- The WAN interface (em0) is directly connected to a cable modem in bridge mode
- The IPs for the WAN interface are acquired via DHCP and DHCPv6 from the ISP
- I'm requesting both an address for the WAN interface and a /56 prefix for the LANs with DHCPv6
- IPv6 connections to external servers work on both the firewall and all clients on the LAN