Messages

DHCPv6 does not provide default gateway information, that's what Router Advertisements are for. And these might get blocked by your vSwitch.

I thought about that as well, but the clients do receive the default gateway when they get their initial DHCPv6 lease. It's also enabled in the Router Advertisements within Opnsense.

I'm experiencing a strange problem with my DHCPv6 setup. All my servers (Windows and Linux) properly receive a few IPv6 addresses from the DHCP servcer running on Opnsense, and are able to access the outside world (e.g. ping google). But after a while (30 minutes or an hour) the connection is severed and ping is no longer possible (Network is unreachable).

During my trial and error investigation process i found out that when this happens, the default gateway has disappeared from the route (both in windows and linux). Trying to renew the lease does not result in the default gateway being re-added. It does work when i force the network interface (networking) on the clients to restart or restart the client server.

The strange thing here, however, is that VMs which run on the same node/host as the Opnsense VM do not seem to experience this behaviour. 

Does anyone here have an idea what might be causing this? This IPv6 network is running on a Hetzner vSwitch. Maybe that vSwitch blocks 'something'?.

Hi,

Following the "Setup SSL VPN Road Warrior" tutorial, I created a VPN server and user, which authenticates using SSL/TLS+User Auth and TOTP. However, every time after an hour, the connection would drop with a log message:

"Inactivity timeout (--ping-restart), restarting"

The VPN client tries to reconnect, but is unsuccessful due to the password (password+googlauth code) no longer matching with what was entered before when the connection was initially created. I've tried setting the renegotiation time to 0, but that did not make a diference. Using password only authentication makes it reconnect just fine.

Then I found in the official OpenVPN documentation the option "auth-gen-token <time in seconds>" which creates an authentication/session token, and keeps this token alive for the time specified. Once the connection reaches that one hour mark, the token is used to re-authenticate instead of the password. Add this option to the "Advanced" field. In addition to this you need to set the Renegotiation time (cannot be set to 0). I set it to the same time as auth-gen-token.

Now, this "Advanced" field has a disclaimer which says "This option will be removed in the future due to being insecure by nature". Maybe it's an idea for the OPNsense team to add the auth-gen-token option to the UI page as a configurable option to compliment the TOTP authentication method.

I thought the problem was solved after setting "Firewall Optimization" from "normal" to "conservative", but this makes the connection disconnect after 15 minutes instead of ~1.

From the Netgate/Pfsense manual which references the optimization settings in more detail, it states that for "tcp.opening No response yet" the setting is 900s or 15 minutes. This would mean that the (initial) connection did not receive a response, eventhough I can use the connection (and get responses on screen) for those full 15 minutes.

( https://docs.netgate.com/pfsense/en/latest/config/advanced-firewall-nat.html )

Any idea if this behaviour can be controlled some more in this firewall? Or see why (if this is the case) the firewall is not receiving a response, or thinks it has not received one, for 15 minutes.

I added another interface (IPv6LAN) and set up DHCPv6 on that one on /80 instead of /64. The end result is the same. Somehow some all outward traffic to port 113 is blocked by the default deny rule, the initial connection to port 6667 is allowed (i can connect and interact to the external irc server), but after ~1.5 minutes all the traffic to 6667 that was allowed before, is suddenly blocked by this default deny rule.

It puzzles me why this port 113 is blocked by the deny rule, and why a connection to an ip/port combination is allowed, and then suddenly disallowed shortly after.

Edit:
I solved the irc disconnecting from port 6667 by changing the setting "Firewall Optimization" from "normal" to "conservative". After changing that setting, the connection is no longer being blocked by the "default deny rule". The block on port 113 persists, but now I start to think it may be caused by a firewall config setting as well, instead of a rule.

That too does not work (i just tried it). I don't see how LAN would mess up this configuration though.

On my opnsense VM, IPv6NET is a WAN interface that's used only for IPv6, because I technically can't have this IPv6 WAN on the regular WAN interface that holds my IPv4 WAN address. I have DHCPv6 enabled on this IPv6NET interface so that I can give out externally reachable IPv6 addresses.

So basically this windows 10 client VM has an internal DHCP provided IPv4 LAN address (192.168.100.209) on one interface, which it also uses to  access IPv4 websites on the internet (through the IPv4 WAN address on opnsense). And on the other interface is a DHCP provided external IPv6 address that is provided by the DHCPv6 service on opnsense on IPv6NET, and has the opnsense IPv6 address (the static IP on IPv6NET interface) as gateway.

So when I go for example to "whatismyip.com" on that windows 10 client to check what my external IP's are, I see for IPv4 the opnsense WAN address and for IPv6 I see the address I received from DHCP.

I did try that as well earlier today, but that did not make a difference. I didn't think it would either because it is able to set up the connection to irc server on port 6667, but seems to selectively block for example port 113.

During that ~1.5 minutes the connection is live I can see it blcoks some higher ports as well. When the connection drops, it shows a few 6667 port blocks with the default deny rule. I observe the same behaviour on other irc ports and other irc servers.

It's probably also not irc specific as I also see other default deny rule blocks happening on for example port 80 and 443. I don't know where those are coming from, but they do originate from my Windows 10 client (not initiated by myself).

As a bit of background, my setup consists of 3 interfaces:

vtnet0 (ipv4 WAN)
vtnet1 (IPv6NET ipv6 WAN)
  - DHCPv6
em0 (LAN)
  - DHCPv4

The windows 10 client has no connection to ipv4 WAN, but only to IPv6NET and LAN. But it is able to go out over ipv4 via the LAN interface.

I'm not sure if a screenshot of the custom IPv6NET rule (see attachment) is what you want to see, or an export of for example the ipv6 part of the rules in "/tmp/rules.debug"

Hi,

I have a strange problem with an IPv6 interface (named in my opnsense as IP6NET). This interface is the interface specific for IPv6 WAN, next to the regular "WAN" interface I use for IPv4. There is also DHCPv6 configured for this interface.

In my network I have a Windows 10 system which receives a DHCPv6 address, and is able to browse IPv6 sites, and is able to connect via IPv6 to my IRC network at port 6667. However, after a minute or so the connection drops. I see in the Opnsense firewall that the connection is allowed, followed by "Default deny rule" blocks for (among others) connections to the same server for port 113 (ident).

After a minute or so, I start seeing the same connection to IRC on port 6667 that had a "pass" before, appearing  in the firewall with a Default deny rule block, after which the IRC connection is disconnected.

This appears to be triggered by firewall rule 10:

@10 block drop in log inet6 all label "02f4bab031b57d1e30553ce08e0ec131"

I also see a lot of Default deny rule hits from this same IPv6 IP on my windows 10 client to addresses on port 80 and 443, which I can browse via IPv6 just fine. Next to the automatically generated rules on the IPv6 interface, I also have one rule that allows all "in" traffic on protocol IPv6* for all source, ports, destinations, etc.

How can I stop the firewall from denying this perfectly fine IPv6 traffic?

Examples from the firewall log where you can see the connection gets a pass (I can connect to 6667), and then after 1.5 minutes the connections to 6667 with the same source and destination gets blocked:

Code Select Expand

IPv6NET Oct 9 18:03:38 [xxxx:xxx:xxxx:c0:20f:ffff:ffff:2000]:64848 [xxxx:xxx:xxx:4488::5]:6667 tcp Default deny rule
IPv6NET Oct 9 18:03:38 [xxxx:xxx:xxxx:c0:20f:ffff:ffff:2000]:64848 [xxxx:xxx:xxx:4488::5]:6667 tcp Default deny rule
IPv6NET Oct 9 18:03:38 [xxxx:xxx:xxxx:c0:20f:ffff:ffff:2000]:64848 [xxxx:xxx:xxx:4488::5]:6667 tcp Default deny rule
IPv6NET Oct 9 18:03:38 [xxxx:xxx:xxxx:c0:20f:ffff:ffff:2000]:64848 [xxxx:xxx:xxx:4488::5]:6667 tcp Default deny rule

IPv6NET Oct 9 18:01:55 [xxxx:xxx:xxxx:c0:20f:ffff:ffff:2000]:113 [xxxx:xxx:xxx:4488::5]:49567 tcp Default deny rule
IPv6NET Oct 9 18:01:51 [xxxx:xxx:xxxx:c0:20f:ffff:ffff:2000]:113 [xxxx:xxx:xxx:4488::5]:49567 tcp Default deny rule
IPv6NET Oct 9 18:01:49 [xxxx:xxx:xxxx:c0:20f:ffff:ffff:2000]:113 [xxxx:xxx:xxx:4488::5]:49567 tcp Default deny rule
IPv6NET Oct 9 18:01:49 fe80::1c97:f31e:7a4:53d8 fe80::d875:32ff:fe3d:fb13 ipv6-icmp IPv6 RFC4890 requirements (ICMP)
IPv6NET Oct 9 18:01:48 [xxxx:xxx:xxxx:c0:20f:ffff:ffff:2000]:113 [xxxx:xxx:xxx:4488::5]:49567 tcp Default deny rule
IPv6NET Oct 9 18:01:48 [xxxx:xxx:xxxx:c0:20f:ffff:ffff:2000]:64848 [xxxx:xxx:xxx:4488::5]:6667 tcp let out anything from firewall host itself

I found out what the problem was. I did not realize that this new interface (IPv6NET) had no firewall rules, and was thus blocking traffic to the fe80 addresses. Once I created an incoming and outgoing rule, I was able to access the outside world.

A simple solution that I completely overlooked  :-[

I think it has something to do with the routing of the fe80 local addresses of the IPv6NET/LAN interfaces. Since I can ping these addresses but cannot go outside with any of these set as default gateway in the client. But when I define the DHCP IPv6 address on the client as static, and manually add a route to the actual address of the default gateway on IPv6NET (xxxx:xxx:xxxx:c0::1), only then I can connect to the outside world from within the client.

So, DHCPv6 advertises the local fe80 address of the interface to the client, but it cannot connect through that. But if DHCPv6 were to advertise the "real" address of the interface's default gateway, it would work. However there's no setting in Opnsense to make it work that way (i think).

Unfortunately this did not work. I cannot assign the IPv6 address to the existing WAN interface, since that one (outside the Opnsense VM) is a different bridge, with a different MTU, than the "IPv6NET" one. The "LAN" interface is also not possible, as that's also another bridge specific for internal IPv4 addresses.

So I now attached another interface to the VM (my Opnsense runs inside a VM), using the same bridge as the one which has the configuration for "IPv6NET", and disabled the already configured DHCPv6 and Router Advertisements on "IPv6NET".

I then configured that new interface, that I call "IPv6LAN", using the configuration you proposed with /80 prefix, but with no specific upstream gateway (Auto Detect). I also created a new DHCPv6 and Router Advertisement for this interface.

The result is the same unfortunately. I do receive a lease that falls within the new specified /80 range. The fe80 default gateway is present in the routing table of the client. I just noticed this gateway address is the same as the local fe80 address (fe80::183e:99ff:fe99:6909) on the "IPv6LAN" interface. However, I still cannot ping anything outside this /80 prefix.

I also noticed I can ping the fe80 address (fe80::d875:32ff:fe3d:fb13) that exists on the "IPv6NET" interface from the client.

I also tried to add that fe80::d875:32ff:fe3d:fb13 address to IPv6LAN as gateway adress (no idea what i'm doing at this point  ::) ), but that doesnt change things either.

Now that I have 2 IPv6 interfaces (IPv6NET that connects to the outside world, and IPv6LAN for DHCP) how would clients that come through IPv6LAN know they should actually go through the IPv6NET interface to the outside world?

Hi,

I have a /64 IPv6 range, and am trying to use part of this range to hand out IPv6 addresses to some of my clients/servers. For this i'm using the DHCPv6 service. However, eventhough my (linux) clients are receiving an IPv6 address from the specified range, they do not receive the IPv6 gateway associated with it. This means these clients can only ping other addresses in my IPv6 space, but nothing outside of it.

The set up as follows (the IP range is partially masked/redacted as xxxx:xxx:xxxx:c0:: ) :

I created an additional interface called "IPv6NET", which has IPv4 disabled and a static IPv6 address (xxxx:xxx:xxxx:c0::299 / 64).

For this interface I also created a gateway which is named "OPT1_GWv6" and has xxxx:xxx:xxxx:c0::1 as address. I was assigned this address by the IPv6 range provider. In the gateway setting I enabled "Upstream Gateway".

With the above setup, this "IPv6NET" interface acts as a second WAN interface, specific for IPv6 communication. I can access the IPv6 enabled outside world from within the Opnsense server.

I then configured a DHCPv6 service for this "IPv6NET" interface, and set the range as xxxx:xxx:xxxx:c0:2f:ffff:ffff:300 - xxxx:xxx:xxxx:c0:20f:ffff:ffff:2000 and populated the "DNS servers" field with the IPv6 google DNS (2001:4860:4860::8888 and 2001:4860:4860::8844). Everything else on this page is left to their default setting.

Under Router Advertisements for "IPv6NET", I set the Router Advertisement to "Managed" and enabled "Advertise Default Gateway". Everything else on this page is left to their default setting. I also tried "stateless" to o get a slaac provided address, which also works to get an address.

When I start my clients, they receive an address that falls within the defined DHCP range, and these leases are shown on the "DHCPv6 / Leases" page, but show as "offline" on that page, and have no MAC address. The DNS servers I defined above are also present on the client, but the gateway is not. The route table on the clients show this:

Code Select Expand

root@ipv62:~# ip -6 route show
::1 dev lo proto kernel metric 256 pref medium
xxxx:xxx:xxxx:c0:20f:ffff:ffff:1fbc dev eth0 proto kernel metric 256 pref medium
xxxx:xxx:xxxx:c0::/64 dev eth0 proto kernel metric 256 expires 86274sec pref medium
fe80::/64 dev eth0 proto kernel metric 256 pref medium
default via fe80::d875:32ff:fe3d:fb13 dev eth0 proto ra metric 1024 expires 1674sec mtu 1400 hoplimit 64 pref medium

I don't know why it shows a local(?) default route address here. Both clients show the same default route.

Anyone here have any idea what might be wrong (or wrongly set)?