Messages

Crowdsec is a good call btw, I did install that the other day for blocking ssh brute forcing. Will check out the rulesets for that... thanks!

Thanks, yeah. I suspect as much.

I just wondered if there was a place for a new firewall option like "maximum number of states in half-open state per IP" which would presumably make this less of an issue as you could start to drop connection requests after (say) 10 or 20 half-open connections had been made from a given IP.

Thanks, but I'm not sure if SYN cookies help here, because it's not causing an issue filling my state table as such - it's more that it's causing damage by reflecting 5x the traffic in SYN-ACK replies to the spoof sender (which presumably it will still do even with SYN cookies enabled?).

Hi there, I just wondered if anyone had any tips on firewall rules to protect against TCP reflection attacks?

Behind my Opnsense box I have an HTTP server, and I have a NAT rule (with associated firewall rule) to redirect traffic from the external port 80/443 to the internal machine port 80/443. I also have a similar rule for IPv6, obviously without the NAT.

What I'm seeing is that I'm getting a lot of half-open connections made at a lowish rate - the remote end is sending a SYN, my server is responding with SYN-ACK (and then sending 5 retries), but I never receive the final ACK.

My guess is this is a reflection attack as because the source IP is repeated many times before changing to another IP in the same network, whereas an attack on my own server would presumably use a random IP every time? See the screenshot attached for an example.

The main problem for me is that it's filling up my log, so I could simply turn off the logging, but i prefer not to do that and also don't want to be the source of a reflection attack if I can help it!

I was looking at the advanced firewall rules to see if I could limit the number of half-open connection per source IP, but I can't find anything to do this specifically. The options available are:

- Max states - no use because this would prevent legitimate connections getting through from other IPs
- Max source nodes - no use because this just limits the total number of source IPs
- Max established - no use because the connections here are not established and still in the half-open state
- Max source states [per IP] - this is the closest thing I need but it would block legitimate clients that are in the established state or waiting to close because it doesn't match only half-open connections
- Max new connections - this would block legitimate clients as it's not per source IP.

Does anyone have any tips on mitigating this scenario?

Thanks
Matt.

Ok, I think I've finally gotten to the bottom of this. Here is the message I sent to Hyperoptic support - I'm hoping they can fix it at their end:

Hi there,

OK, I think I now understand what is going on here, and I have a temporary workaround. However, I think it possibly highlights an issue at the Hyperoptic end, and I would like to know what you think. Please could you pass this message onto one of your network engineers?

The problem seems to be with the way the Hyperoptic gateway interprets NDP neighbour advertisements from my third party router. Before the DHCPv6 handshake, the gateway sends an NS to my router, which my router responds to correctly. The NA reply has the 'R' flag set (which is correct, because it is a router and forwards ipv6). I noticed that the stock ZTE router sends its initial NA /without/ the 'R' flag set. I think because my router sets the flag, the Hyperoptic gateway discards my NA, and so cannot communicate with my router. Ping6's to the gateway from my router fail. The workaround is to disable DHCPv6 on my router, and switch to a static IPv6 configuration with just a link-local address while ping6'ing the gateway. This causes my router to send an NA *without* the R flag set, and the Hyperoptic gateway no longer ignores it. I can then successfully ping the gateway!

If I then switch the router back to DHCPv6, it can then successfully complete the DHCPv6 handshake and get allocated its /56. Because the NA is cached, things then continue to work. Is it by design that the Hyperoptic gateways behave in this way?

It would be good if it could be fixed, as the workaround isn't ideal as it requires manual intervention (and I'm also not sure if things will break again when the NA expires, or the Hyperoptic gateway is reset - which is guess what happened when my package was upgraded).

Many thanks
Matt.

Worth mentioning that I don't think this is a firewall issue as (a) I tried turning off the packet filtering and (b) I also did a capture using a managed switch with mirrored ports on the WAN port and didn't see any NDP advertisements either. I initially thought this was an ISP issue (as it worked before), but I don't understand why it is fine from my Mac.

Thanks!

Hey there,

Does anyone here use Opnsense with Hyperoptic in the UK?

IPv4 works great, but in the past I've had some trouble with IPv6 (see https://forum.opnsense.org/index.php?topic=19600.msg90614#msg90614). Despite this, IPv6 randomly started working one day and has been fine ever since...until now :-(.

The other day Hyper upgraded my package to a faster speed, and since then IPv6 seems to have gotten broken.

I've tried pinging the ISP's upstream gateway, but without success. Running tcpdump in another session, you can see that there are NDP solicitations being sent but I do not receive a reply advertisement from the ISP gateway:

$ ping6 'fe80::fa98:efff:fe73:892b'%igb0
...

$ tcpdump ip6
07:47:37.629209 IP6 fe80::xxxxxxx > ff02::1:ff73:892b: ICMP6, neighbor solicitation, who has fe80::fa98:efff:fe73:892b, length 32

The ISP supplied router seems to work fine with IPv6. Also if I connect my Mac directly to the ISP ethernet socket, then I can successfully ping6 the ISP upstream gateway, and I can see that neighbor advertisements are received correctly via wireshark.

Has anyone seen anything like this before? Are there any settings or tweaks that I could try making?

Note: As in my previous post, I'm still suspicious as I do not see any MLDv2 packets being sent from opnsense (and these are being sent from the Mac) - I'm not sure if this might have any effect on my ability to receive NDP replies?

Any help anyone can offer would be much appreciated as this is driving my nuts!
thanks
Matt.

Thanks @marjohn56, it's definitely working with the IPv6 test site.

Also, I've saved the DUID and disabled release - good call on that.

Thanks again for all your help
Matt.

Hi there,

Apologies - this is a dumb newbie question, but I'm trying to get my head around the default firewall rules for DHCP (v4 and v6):

[1] IPv6 UDP   fe80::/10   546   fe80::/10   546   *   *   allow dhcpv6 client in WAN   
[2] IPv4+6 UDP   *   547   *   546   *   *   allow dhcpv6 client in WAN   
[3] IPv4+6 UDP   *   546   *   547   *   *   allow dhcpv6 client in WAN   
[4] IPv4+6 UDP   *   67   *   68   *   *   allow DHCP client on WAN   
[5] IPv4+6 UDP   *   68   *   67   *   *   allow DHCP client on WAN

I understand rule [1] - as it's on the link local address (which is used for IPv6 AIUI).

But for [2], [3], [4] and [5] is there a risk with these rules as they use the wildcard address - and are not restricted to the link local address (for IPv6) or the broadcast address (for IPv4)?

Is there a risk with these rules that someone could someone on the internet inject malicious packets to clients on their DHCP client port (or indeed to the DHCPv6 server on the LAN interface?). I've almost certainly missed something here but keen to understand!

thanks
Matt.

I should add, at first I didn't seem to manage to get IPv6 working on the router itself (but it is working now, weirdly).

If this happens, set "Prefer IPv4 over IPv6" in Settings > General, otherwise I found the router was unable to check for firmware updates.

Thanks everyone for the help, especially @marjohn56 for the detailed suggestion re the DUID!

Weirdly, the next day, everything seemed to start working fine without any real changes.

I'm wondering if perhaps the stock router's previous lease eventually expired and unblocked the connection? NB. I had previously done some experiments with MAC spoofing, but it didn't really help, and eventually it seemed to work without it (and without spoofing the DUID). So who knows!

I also did see a problem early on where the IPv6 connection would sometimes lose its route overnight (much like other people have mentioned on this thread!). I changed the settings to not allocate an IP to the router itself via DHCPv6 (just a /56 prefix), and that /may/ have fixed it. I still seem to have an IPv6 address on the router's WAN port, but that must have been set via SLAAC (and reading other threads a mixed approach of DHCPv6/SLAAC seems to what Hyperoptic require).

So, everything is now working great, but I'm keeping an eye on it and have setup monitoring via smokeping on an internal host to see if there are any further issues. 🤞🏻🤞🏻🤞🏻🤞🏻

If others are seeing the connection drops, try "Request only an IPv6 prefix" as I think that may have been what fixed it for me.

thanks again everyone,
Matt.

Hi there,

I'm a newbie to OPNsense, and have installed 20.7.3 on my PCengines APU2 box. I'm really impressed with how powerful and easy to use it is! Nice work and thanks :-).

IPv4 is working great, but i'm having some issues with IPv6. It works fine with the ISP's stock (ZTE) router, but I can't get it to work with OPNsense.

My ISP is Hyperoptic (UK) who run ethernet to the premises and then support native IPv6 - allocating a /56 prefix via DHCPv6 and configuring the router's own address using SLAAC.

After a lot of experimentation, I ended up using a managed switch with port monitoring to intercept the traffic to compare the two routers. Please see the screenshots below:

ISP router (ZTE):
http://www.holgate.org.uk/working-isp-router.png

Opensense:
http://www.holgate.org.uk/not-working-opnsense.png

The main thing i noticed was that OPNsense doesn't appear to be sending MLDv2 announcements.

Ultimately I seem to be unable to ping6 the ISP's router, and using the ndp command, I can see that I'm unable to resolve the MAC address. I was wondering if this might be due to the lack of Multicast Listener Report packets?

I did a bit more experimentation using tcpdump and mtest and noticed that these announcements were being sent fine on igb1 (LAN), but not on igb0 (WAN).

I tried lots of different config changes (including completely disabling packet filtering), but to no avail. Occasionally a packet would seem to slip through and be visible via tcpdump, but I've no idea what changed to allow this.

I just wondered if anyone has any insights into this problem as it's driving me crazy and not sure what else to try!

Many thanks in advance,
Matt.