Messages

One thing I just noticed it that I can ping the IPv4 gateway:

Code Select Expand


root@opnsense:/home/chenxiaolong # ping -c 1 174.100.64.1
PING 174.100.64.1 (174.100.64.1): 56 data bytes
64 bytes from 174.100.64.1: icmp_seq=0 ttl=255 time=23.105 ms

--- 174.100.64.1 ping statistics ---
1 packets transmitted, 1 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 23.105/23.105/23.105/0.000 ms


but pinging the IPv6 gateway fails with "No route to host":

Code Select Expand


root@opnsense:/home/chenxiaolong # ping6 -c 1 fe80::201:5cff:fe8d:9c46%em0
PING6(56=40+8+8 bytes) fe80::7285:c2ff:fecd:bcf5%em0 --> fe80::201:5cff:fe8d:9c46%em0
ping6: sendmsg: No route to host
ping6: wrote fe80::201:5cff:fe8d:9c46%em0 16 chars, ret=-1

--- fe80::201:5cff:fe8d:9c46%em0 ping6 statistics ---
1 packets transmitted, 0 packets received, 100.0% packet loss


(but again, curling https://www.example.com over IPv6 on the firewall works, so I assume the gateway is fine)

Not sure if pinging the IPv6 gateway is ever supposed to work. I'm still learning IPv6 :)

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:

Code Select Expand


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 Expand


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 Expand


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