IPv6 and Bridge
-
Hi Everyone,
Sorry if this has been asked before, but I coudn't find anything in the search specific to my case.
I understand that pfsense doesn't support IPv6 filtering. We current have a bridge between WAN and LAN, and pfsense is used to do filtering. Would IPv6 be able to pass (unfiltered) through a pfsense bridge?
Thanks
-
I don't believe it will, not without some major behind-the-scenes tomfoolery with the pf rules.
-
Ok, can you please help me with a configuration then that doesn't use bridging then, that will allow pfsense to pass through ipv6 traffic?
basically, my colo has "dual stacked" my network connection, so I have access to a bunch of ipv4 and ipv6 addresses on my WAN interface. Currently, for IPv4 traffic, I use pfsense as a bridge firewall.
Any help is appreciated
Many Thanks
-
Just to let you know of something that i've tried.
In my LAN rules, I have allowed all outgoing of any src/dst IP address.
Looking at tcpdump on pfsense, I can see that the IPv6 solicitation (similar to an ARP who-has) is successfully going out via the WAN interface. I can also see an advertisement (similar to an ARP is-at) successfully coming in on the WAN interface from the remote machine being pinged, however pfsense won't let it pass to the LAN interface. I have also enabled an allow all at the bottom of my WAN rules for any arc/dst.
Any ideas?
Thanks
-
Oh and in the firewall log, I can see the incoming advertisement packet being block due to the following:
@2 scrub in on em0 all fragment reassemble
@2 block drop in log all label "Default deny rule"Any ideas?
Thanks
-
It seems to go through ok when I place a single "Allow all" rule in the floating rules tab for my WAN and LAN interface.
I take it this is insecure? At what point do these "Floating Rules" get evaluated?
Thanks
-
I'm not sure of the order, but I think it may be the same as the order indicated by the ID # shown in the URL for edit page.
If you want to allow all IPv6, but still have basically normal operation for IPv4, make sure the rule has "Apply the action immediately on match." unchecked and make two block rules under it that also have that unchecked. For one of the rules, specify 0.0.0.0/31 for source, and use 128.0.0.0/31 for the other rule. Use any for protocol and destination. Select in for the direction on these two rules. If you only care about blocking things coming in on WAN, just select WAN. Otherwise, select the other interfaces you want it to apply to, but if you do this you may need to add additional rules on LAN, etc. to allow DHCP, DNS, HTTP, HTTPS, or other services into the router.
-
Hi Efonne,
Thank you for your helpful post. Just before I put these 2 rules in I've got a few questions:
- Should these 2 new blocks rules appear above or below the "Allow everything" rule?
- If I put these 2 rules in, do I need to manually put in other rules to allow incoming IPv4 services on the WAN (e.g. web server)?
Thanks
-
The two rules should go below the allow everything rule, since you will be having "Apply the action immediately on match." unchecked on the 3 rules. Rules are evaluated top to bottom, but with that unchecked (something you can only do on the floating rules), it will only apply the action from the last matching rule of that type, waiting until it hits the end of the rule list, a rule that matches and has that checked, or a regular rule from one of the tabs with an interface name.
It is kind of complicated to explain, but basically if you have "Apply the action immediately on match." unchecked on those 3 rules, the rules on the tabs for the interfaces or anywhere else can still override it. Some of the built-in hidden rules, like the default deny rule, are made this way. They are actually above other rules in the list, but allow other rules after them to match traffic and override them.