Messages

It's kind of funny, people said the same thing about 19.1 -> 19.7 and here we are talking about 19.7 -> 20.1 with all the same patching in place since a year and literally no info beyond "it broke". I am not sure what to make of it honestly and it's not enough information to start looking.


Cheers,
Franco

Just wanted to know if it was worth doing a re-install.

So, downloaded a new 20.1 ISO, did a fresh install. Went through the wizard and then added the IPv6RD details under the WAN interface.

Copy/paste from my ISP into OPNsense to avoid any typos.

Code Select Expand


IPv4 BR adresse: 213.167.115.92
IPv4 Prefix: 0
IPv6 Prefix: 2a01:79c::/30

In 19.7 it then gets an IPv6 address and I can ping6 2606:4700:4700::1111.

In 20.1 the LAN insterface gets an address but the WAN don't get an IPv6 address when looking at the interfaces widget or under interfaces > overview. I do however get an IPv6 in the console.. If I try to ping6 I get

Code Select Expand

# /sbin/ping6 -c '3' '2606:4700:4700::1111'
ping6: UDP connect: No route to host

In the logs there's no mention of wan interface, just that the lan interface gets an adress based on the external IPv4 and this

Code Select Expand

2020-02-03T10:29:54 opnsense: /usr/local/etc/rc.newwanip: ROUTING: skipping IPv6 default route
2020-02-03T10:29:54 opnsense: /usr/local/etc/rc.newwanip: ROUTING: IPv6 default gateway set to wan

Not sure what else I can provide for you, screenshots or logs?

Edit: Since it complains about no route, I guess it would make sense to include this

Code Select Expand

Proto Destination Gateway Flags Use MTU Netif Netif (name) Expire
ipv6 ::1 link#5 UH 0 16384 lo0
ipv6 2a01:79c:ceb9:2b78:: link#9 UHS 0 16384 lo0
ipv6 2a01:79c:ceb9:2b78::/64 link#2 U 36 1500 vtnet1 lan
ipv6 2a01:79c:ceb9:2b78::/62 link#9 U 0 1280 wan_stf
ipv6 2a01:79c:ceb9:2b78::1 link#2 UHS 0 16384 lo0
ipv6 fe80::%vtnet0/64 link#1 U 0 1500 vtnet0 wan
ipv6 fe80::28c4:fbff:fefd:3f37%vtnet0 link#1 UHS 0 16384 lo0
ipv6 fe80::%vtnet1/64 link#2 U 178 1500 vtnet1 lan
ipv6 fe80::547a:d1ff:fe2c:ec7a%vtnet1 link#2 UHS 0 16384 lo0
ipv6 fe80::%lo0/64 link#5 U 0 16384 lo0
ipv6 fe80::1%lo0 link#5 UHS 0 16384 lo0

I just spun up a fresh instance of 19.7 and IPv6RD worked. Upgraded to 20.1 and can't get an IP anymore. Anyone else got it working?

Changing to pfsense pretty much solved all my issues.

It took me under an hour to set up pfsense with
- IPv6RD (broken again in opnsense)
- Port forwarding (for some reason one of my rules stopped working when upgrading to 19.7 and I've been unable to get it working again)
- Port forwarding through a VPN provider (unable ot get that working through several iterations of opnsense, worked first attempt on pfsense)

I'm sorry to leave as I very much prefer opnsense, unfortunately one of my requirements is that my firewall should work. I think the last time I had everything working without issues was on 17.X. Even tried a fresh install without joy.

Thanks for letting us know, I've also looked into migrating to pfsense but haven't found the time yet. I had port forwarding working on 18.something so it did work in the past. Not sure when it broke.

Since this seems to be a difficult issue, would it be a viable solution to set up a second OPNsense instance that routes all traffic over the VPN? Would the double NAT be an issue after the tunnel is established?

My VPN client settings in case that has something to do with it

Does any of this help?

Packet capture showing that the packets hit the firewall so that the port forwarding at the VPN providers side is working.

Code Select Expand

Capture output
10:32:21.481369 AF IPv4 (2), length 52: (tos 0x0, ttl 118, id 50601, offset 0, flags [none], proto UDP (17), length 48)
    41.220.30.38.17052 > 10.11.0.7.31353: [udp sum ok] UDP, length 20
10:32:21.481451 AF IPv4 (2), length 52: (tos 0x0, ttl 117, id 50601, offset 0, flags [none], proto UDP (17), length 48)
    41.220.30.38.17052 > 192.168.1.211.31353: [udp sum ok] UDP, length 20
10:32:22.128435 AF IPv4 (2), length 64: (tos 0x0, ttl 58, id 20939, offset 0, flags [DF], proto TCP (6), length 60)
    34.73.85.159.57694 > 10.11.0.7.31353: Flags [S], cksum 0x7efc (correct), seq 145608005, win 28400, options [mss 1357,sackOK,TS val 170368142 ecr 0,nop,wscale 7], length 0
10:32:22.128506 AF IPv4 (2), length 64: (tos 0x0, ttl 57, id 20939, offset 0, flags [DF], proto TCP (6), length 60)
    34.73.85.159.57694 > 192.168.1.211.31353: Flags [S], cksum 0xc692 (correct), seq 145608005, win 28400, options [mss 1357,sackOK,TS val 170368142 ecr 0,nop,wscale 7], length 0
10:32:22.240453 AF IPv4 (2), length 64: (tos 0x0, ttl 56, id 55812, offset 0, flags [DF], proto TCP (6), length 60)
    69.136.134.174.31886 > 10.11.0.7.31353: Flags [S], cksum 0xb8bb (correct), seq 2722786196, win 65535, options [mss 1357,sackOK,TS val 49000848 ecr 0,nop,wscale 8], length 0
10:32:22.240523 AF IPv4 (2), length 64: (tos 0x0, ttl 55, id 55812, offset 0, flags [DF], proto TCP (6), length 60)
    69.136.134.174.31886 > 192.168.1.211.31353: Flags [S], cksum 0x0052 (correct), seq 2722786196, win 65535, options [mss 1357,sackOK,TS val 49000848 ecr 0,nop,wscale 8], length 0

NMAP showing that the port is filtered

Code Select Expand


$ nmap -p 31353 185.65.134.166

Starting Nmap 7.40 ( https://nmap.org ) at 2019-06-28 08:32 UTC
Nmap scan report for 185.65.134.166
Host is up (0.093s latency).
PORT      STATE    SERVICE
31353/tcp filtered unknown

Nmap done: 1 IP address (1 host up) scanned in 1.06 seconds

If I remove the firewall rule I can see that the packets are blocked but with a rue under floating or the VPN interface they show as pass



Any ideas? Or suggestions to what would be useful to look at? I suspect the problem is the reply-to address but I'm not sure how to troubleshoot it

Port forward behind VPN

I made a similar post a while back when I used PIA and couldn't get it to work. I switched to Mullvad (they let you keep a fixed port) and got it working straight off the bat. I had some computer issues (non OPNsense related) and had to set everything up from scratch. Now I can't get it working anymore..


I've set up the VPN client, assigned it an interface and that works as it should. I've set up a rule on the LAN interface:

Code Select Expand

Pass
LAN Interface
IPv4
Any protocol
VPN alias source
Any destination
Any port
VPN Gateway


I've got a rule below that on the LAN interface to block traffic when the VPN client is down:

Code Select Expand

Block
LAN interface
IPv4
Any protocol
VPN alias source
Any destination
Any port
Default gateway

So far so good, when I down the VPN client the traffic is blocked.


I then have manual outbound NAT:

Code Select Expand

VPN interface
IPv4
Any protocol
VPN alias source
Any destination
Translation/target interface address


For the port forwarding I've tried multiple ways but this is the current one


Firewall: NAT: Port forward

Code Select Expand

VPN interface
IPv4
TCP/UDP
Any destination
Destination port alias (Port opened at Mullvad)
Redirect to single host IP
Redirect to targe port HTTP
NAT reflection on
Add associated filter rule


I've set up an Nginx server listening at the end just to make it as simple as possible. Locally it works (with the NAT reflection) but no response from external network or remote port checkers. I can see the packets being allowed through the firewall directed to the correct LAN IP but it's like they don't get routed back out the correct way.


I've tried making a manual rule for NAT under the VPN interface and as a floating rule. Any suggestions would be highly appreciated.

Hi

It's been a little more than a week:) DDNS works as expected now with IPv6. Thank you very much for that:)

It's not really an issue but just thought I'd let you know that the Interfaces widget still doesn't show an IPv6 (at least for me) and the WAN interface doesn't either (Interfaces -> Overview). I can't really be more helpful than that though.

Just add a rule allowing all traffic? Firewall rules are executed on first match so then the deny rule shouldn't matter.

That's great;) This was just for me playing around so definitely no rush on my part, appreciate all the hard work you do:)

Could this also be related to the interfaces widget not showing an IPv6?

Yeah, I was thinking from a LAN device to see if it's simply a DNS issue. Thinking about it it's most likely not since you can ping6 google.com from the firewall itself.

I'd check if your device actually has an IPv6 first. They'll have an fe80 or something address at least but you'll also need a global one in the same scope as your LAN interface.

Have you enabled RA and DHCPv6? Have you allowed IPv6 ICMP through your firewall?

Just a heads up, I'm fairly new to IPv6 myself and are still figuring things out so I'm probably not the best person to help troubleshoot this

Can you ping 2606:4700:4700::1111 ?

Have you tried http://ipv6-test.com/ ?

Might help you understand where it fails.

Have you enabled IPv6 on your devices? Do you have a link-local address at least?

I'm not sure if this is an issue or if I'm just misunderstanding something.

I've got IPv6 set up and it's working fine. I can ping6 google.com and I can access ipv6.google.com just fine from any device on my network. IPv6 test sites also reports everything fine.

So today I decided to include my IPv6 in my DNS. I've got a CNAME pointed at DuckDNS which works fine for IPv4 but fails for IPv6 with "Aborted IPv6 detection: no address for re1"

When checking the WAN interface (Interface widget and Interfaces -> Overview) it does in fact seem like it doesn't have a global IPv6, just a link-local address. The LAN interface has a global address.

I can however ping6 google.com just fine from my WAN interface, it also shows me the WAN IPv6 address.

--- google.com ping6 statistics ---
3 packets transmitted, 3 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 16.717/16.789/16.884/0.070 ms


So, shouldn't OPNsense show that the WAN interface does in fact have an IPv6 configured or is it just something misconfigured at my end?