Messages

Well, to be honest I do not remember why Direct LAN IPV6 to Firewall (LAN net -> This Firewall) rule is there. Perhaps some experiments I've done long time ago. It shouldn't do harm, though. Am I wrong?

At the moment I am thinking of bringing up an opnsense instance in a VM to see if I can reproduce it with minimal customisations, as the last option. Unfortunately, I won't happen any time soon. Any further troubshooting tips greatly appreciated.

Unfortunately I an not sure what is the best way to pull that information (please let me know if grep SOMETHING /tmp/rules.debug will be better), here is what I have in GUI: Firewall -> Rules -> LAN (there are mostly default, IIRC):

• Anti-Lockout Rule (it's both v4 and v6 if I am not mistaken)
• Direct LAN IPV6 to Firewall (LAN net -> This Firewall)
• Default allow LAN IPv6 to any rule (LAN net -> any)

Thanks

Right, from the shell on the opnsense box I only get

Code Select Expand

opnsense@OPNsense:~ % curl -6 http://google.com/
curl: (7) Failed to connect to google.com port 80: Operation timed out


P.S. the same for root user:

Code Select Expand

root@OPNsense:~ # curl -6 http://google.com/
curl: (7) Failed to connect to google.com port 80: Operation timed out


Well, as far as I can test everything mostly works, except outbound v6 data transmission to the opnsense box itself. LAN is fully v6 enabled and LAN clients have no issues with v6 connectivity. Not a complete list, but some of the major cases I can think of:

• ping6 opnsense works from (any) LAN host
• ping6 google.com works from (any) LAN host
• traceroute6 google.com works from (any) LAN host
• curl -6 http://google.com/ works from (any) LAN host
• curl -6 http://LAN-PLEX-WEB/ works from a LAN host

• ping6 from opnsense to any LAN host works
• traceroute6 from opnsense to any LAN host works
• curl -6 http://LAN-PLEX-WEB/ works from opnbox

• ping6 google.com works from opnsense box
• traceroute6 google.com works from opnsense box

Pings work from command line (using the default source address), and from Interfaces -> Diagnostics:

• v4 ping works from default, LAN, localhost, OpenVPN
• v6 ping works from default, LAN
• v6 ping does NOT work from localhost (sendmsg: No route to host) and OpenVPN (0 packets received, but it's a site local address, not routable)

Code Select Expand


$ netstat -r
Internet6:
Destination        Gateway            Flags     Netif Expire
::1                link#5             UH          lo0
2000::/3           ovpnc2             US       ovpnc2
XXXX:YYY:ZZZ::/64  link#2             U          igb1
XXXX:YYY:ZZZ::8001 link#2             UHS         lo0
fd9d:a224:acef::/1 link#9             U        ovpnc2
fe80::%igb0/64     link#1             U          igb0
fe80::20d:b9ff:fe4 link#1             UHS         lo0
fe80::%igb1/64     link#2             U          igb1
fe80::20d:b9ff:fe4 link#2             UHS         lo0
fe80::%lo0/64      link#5             U           lo0
fe80::1%lo0        link#5             UHS         lo0
fe80::%ovpnc1/64   link#8             U        ovpnc1
fe80::20d:b9ff:fe4 link#8             UHS         lo0
fe80::20d:b9ff:fe4 link#9             UHS         lo0
fe80::%pppoe0/64   link#11            U        pppoe0
fe80::20d:b9ff:fe4 link#11            UHS         lo0
feed::/112         link#9             U        ovpnc2
feed::1002         link#9             UHS         lo0


XXXX:YYY:ZZZ -- internal prefix, NPT'ed to external one. XXXX:YYY:ZZZ::8001 -- opnsense box address

So the one of few things that does NOT work from opnsense box is curl -6 http://google.com/

Please let me know if I have missed any important pieces.

Thanks.

OK, since I am not quite ready to give up my IPv6 connectivity yet, I spent some time looking at tcpdump output (for curl -6 http://google.com/), and here is what I see:

• Outbound packets are leaving with correct(ly NPT'ed) address, which corresponds to an externally visible IPv6 address on the opnsense box itself
• Response packets arrive to the same (correct external IPv6)
• But eventually packets never reach the curl socket, which to me means that either NPT does not catch them or some firewall rules block them directly

I suspect some changes either in NPT or default firewall rules broke my set up, but I have no idea how to troubleshoot it further. At the moment I do not have enough time to turn off NPT, and ultimately I do not want to do this either.

Could someone please give me an advice how to trace those incoming packets further, after I see them on ovpnc interface? Like I said they are clearly either not NPT'ed properly or reject by some new firewall rules.

Good, there are at least two of us affected. I am afraid my setup is unnecessary complicated (historical reasons), but hopefully dcol's set up is simpler.

Anyway, my ISP has no IPv6, so I use a tunnel to my own server, which has native IPv6. ISP gives me DSL (FTTC) PPPoE link, but again it's v4 only. Technically, that "tunnel" I have is just an openvpn connection, which encapsulates both IPv4 and IPv6 for simplicity. So everything that leaves my LAN goes through VPN. OpenVPN uses site local feed::/112 for the link itself. VPN server uses a different v6  network for itself. Allocation is static for the router, other LAN hosts mostly use SLAC (DHCPv6 is configured, but mostly unused AFAIK). Naturally, for all that to work I have a routed block, which is used by openvpn connection (iroute-ipv6).

And now there is an unusual part of my set up: I have NPT (NPTv6 in 18.x) to translate my internal network. This is a legacy thing, not really used anymore, just left there because it was working fine. Translation is done for two real/routable addresses, the LAN does NOT use ULA.

Thanks

So I waited for 18.1.2 to be ready and upgraded my up-to-date 17.x box. It went to 18.1.1 only, but for LAN clients everything was working fine (including IPv6). Then I decided to upgrade to 18.1.2 and it was "aborted internally". opnsense-update was hanging on pkg-static invocations.

Well, I thought, I've seen something similar when I had my IPv6 misconfigured. And I tried the relevant pkg operations with -4 flag. It worked. Ooops.

Now, everything was working fine (especially regarding the IPv6 for LAN clients and router itself) on 17.x. But after upgrade only router itself has no IPv6 connectivity. The pings and traceroute6 seems to be working, but no actual data is going through (e.g. curl -6 http://google.com/ just times out without receiving anything).

Any advice appreciated on how to debug it further.

Hi!

I was recently forced to review my OpenVPN configuration, and I quickly realised that I have OpenVPN 2.4.x on all devices. I immediately thought about turning on tls-crypt, but I am not sure what would be the most elegant way to do so. It looks like the GUI supports tls-auth only.

I can surely dump the secret somewhere (using SSH) and just put tls-crypt /path/to/key in the "advanced" text box. But I was wondering if there is a more transparent way to achieve it? Ideally with all steps done via the web GUI and thus keeping the tls-crypt key as a part of the backup XML.

Thanks!

Found it :) One should never assemble configuration from bits and pieces over a month.

It was using the same v6 net for the VPN link itself. Once I switched the VPN to use ULA addresses for the link, it all works just fine.

Dear helpful opnsense users,

This is follow up question for my update-related question[1], which turned out to be an IPv6 connectivity issue. I suspect it might be something known and straightforward.

I have an OpenVPN tunnel set up on opnsense box, with all the traffic (IPv4 and IPv6) going through the tunnel. My ISP does not provide v6 connectivity, so v6 has only one way out - via VPN (for v4 I have "kill switch" floating rule). VPN server assigns routed X.Y.Z::/64 network to the opnsense. Opnsense box uses NPT to translate it to/from internal network A.B.C::/64 (not site local, a regular net for historical reasons, using the "OpenVPN" interface, I did not assign one manually via Interfaces -> Assignments). LAN boxes get their IPv4 and IPv6 connectivity, and all seems to be OK.

Now, I recently found that the opnsense box itself has no IPv6 connectivity (due to NPT?). Here is what happens:

When I ping6 google.com from a LAN machine I see the following going out (and in) via the vpn interface:

Code Select Expand

# tcpdump -i ovpnc2 icmp6
12:30:00.852675 IP6 X:Y:Z:0:b4f3:a128:d588:5fa6 > lhr35s07-in-x0e.1e100.net: ICMP6, echo request, seq 1, length 64
12:30:00.863742 IP6 lhr35s07-in-x0e.1e100.net > X:Y:Z:0:b4f3:a128:d588:5fa6: ICMP6, echo reply, seq 1, length 64


However, when I do the same from the opnsenses box, I see:

Code Select Expand

# tcpdump -i ovpnc2 icmp6
12:32:25.379827 IP6 A:B:C::1002 > lhr35s07-in-x0e.1e100.net: ICMP6, echo request, seq 0, length 16
12:32:26.442561 IP6 A:B:C::1002 > lhr35s07-in-x0e.1e100.net: ICMP6, echo request, seq 1, length 16


It looks like it takes the external address assigned to the ovpnc2 interface by the server (X.Y.Z::1002), do NPT for that address (which results in the internal A.B.C:: prefix) and then sends it out. Basically, address A.B.C::1002 does not exist anywhere, the ovpnc2 interface has address X.Y.Z::1002.

I appreciate any pointers, how do I debug it further?

Thanks a lot.

1. https://forum.opnsense.org/index.php?topic=6033.0

Oh, while I am quite sure there was/is no proxy involved, that sent me in the right direction. Thanks a lot!

Most likely it was my (broken) IPv6 setup. There was, however an additional change in opnsense which triggered something, since I have not touched anything for at least 6 months.

Anyway, in my case the root cause was as follows: the opnsense box itself had no IPv6 connectivity (while the LAN and WAN were IPv6 enabled). I'll post a separate question later.

Folks,

There is a strange problem with my opnsense install. I was wondering if somebody has any ideas how to resolve or at least troubleshoot it further.

I've skipped 17.7.2, as I was away for a while. Since 17.7.3 became available, the update UI always fails with "Firmware status check was aborted internally. Please try again." Often the "Update"/"Plugins"/"Packages" tabs are unusually empty. In the logs I see "config.d.py [...] returned exit status 1"

Doing opnsense-update from the command line seems to work, but it is extremely slow, takes approximately 10 minutes (mostly while doing pkg-static update and pkg-static upgrade) to check the status and then it took hours to upgrade to 17.7.3.

Another strange thing: update UI "thinks" the system is stuck at 17.7.1 (that's the latest version shown), while upgrade to 17.7.3 seems to be successful and dashboard says "OPNsense 17.7.3-amd64"

Reboot doesn't change anything. I tried multiple update mirrors, but there is no difference in timing.

Thanks a lot.