You can not assign the IPv6 Gateway to a IPv4 Filter rule

jasonlitka · Sep 24, 2011, 2:15 PM

… but I'm not. I created a Tier 1/Tier 2 failover routing group using two IPv4 gateways (OPT1 & WAN) and tried to assign it to an IPv4 filter rule and I got the error:

If I try changing the filter rule to IPv6 I get:

You can not assign a IPv4 gateway group on IPv6 Address Family rule
You can not assign the IPv4 Gateway to a IPv6 Filter rule

Any thoughts?

databeestje · Sep 24, 2011, 9:17 PM

Will look into it. Need to setup test environment first though.

oddworld · Oct 2, 2011, 9:37 AM

+1 on this

Setup

WAN1 = ipv4 static assignment
WAN2 = ipv4 static assignment
IPv6 = HE tunnel via WAN1

ipv4 single gateway works
ipv6 works as expected

databeestje · Oct 18, 2011, 7:38 AM

I've just added a fix for this issue but it might not be the entire fix. I am lacking a multiwan install right now to test.

A quick test shows that it should now work as intended. Sorry for the inconvienence. I did not have time earlier.

jasonlitka · Oct 18, 2011, 2:51 PM

@databeestje:

I've just added a fix for this issue but it might not be the entire fix. I am lacking a multiwan install right now to test.

A quick test shows that it should now work as intended. Sorry for the inconvienence. I did not have time earlier.

I can test it when I get home if you can tell me how to update to the newest code.

databeestje · Oct 18, 2011, 6:53 PM

you will need to gitsync your install using the instructions in the board welcome message.

jasonlitka · Oct 18, 2011, 8:42 PM

@databeestje:

you will need to gitsync your install using the instructions in the board welcome message.

Oh, that it? I didn't know if 2.1 had moved to FreeBSD 9.0 yet. Guess not.

Anyway, as soon as I did that I got a bunch of alerts in the UI telling me I have syntax errors and pf rules will not be loaded… I'm not rebooting yet as I'm not sure it's safe to do so.

Oct 18 16:35:26 	php: : There were error(s) loading the rules: /tmp/rules.debug:192: rule label too long (max 63 chars) /tmp/rules.debug:194: rule label too long (max 63 chars) /tmp/rules.debug:196: rule label too long (max 63 chars) /tmp/rules.debug:198: rule label too long (max 63 chars) pfctl: Syntax error in config file: pf rules not loaded - The line in question reads [192]: pass in quick on $LAN inet proto { tcp udp } from 192.168.218.0/24 to <negate_networks> keep state label "NEGATE_ROUTE: Negate policy routing for vpn, static routes and direct networks"
Oct 18 16:35:26 	php: : New alert found: There were error(s) loading the rules: /tmp/rules.debug:192: rule label too long (max 63 chars) /tmp/rules.debug:194: rule label too long (max 63 chars) /tmp/rules.debug:196: rule label too long (max 63 chars) /tmp/rules.debug:198: rule label too long (max 63 chars) pfctl: Syntax error in config file: pf rules not loaded - The line in question reads [192]: pass in quick on $LAN inet proto { tcp udp } from 192.168.218.0/24 to <negate_networks> keep state label "NEGATE_ROUTE: Negate policy routing for vpn, static routes and direct networks"
Oct 18 16:35:26 	php: : The command '/sbin/pfctl -o basic -f /tmp/rules.debug' returned exit code '1', the output was '/tmp/rules.debug:192: rule label too long (max 63 chars) /tmp/rules.debug:194: rule label too long (max 63 chars) /tmp/rules.debug:196: rule label too long (max 63 chars) /tmp/rules.debug:198: rule label too long (max 63 chars) pfctl: Syntax error in config file: pf rules not loaded'</negate_networks></negate_networks>

EDIT #1: As a plus though, I can now add a gateway group to a filter rule.

EDIT #2: The annoying alert comes back any time I edit a filter rule.

databeestje · Oct 19, 2011, 8:48 PM

I have a hunch that filter rule on line 192 of the rules.debug is a negate rule. Can you verify please.

I will check as well

jasonlitka · Oct 20, 2011, 2:57 PM

Line 192 is:

pass  in  quick  on $LAN inet proto { tcp udp }  from 192.168.218.0/24  to <negate_networks> keep state  label "NEGATE_ROUTE: Negate policy routing for vpn, static routes and direct networks"</negate_networks>

jasonlitka · Oct 30, 2011, 3:28 PM

@Jason:

I'm not rebooting yet as I'm not sure it's safe to do so.

The answer was "no", it was not safe to restart. I lost power yesterday for an instant (October snowstorms, go figure) and when my box came back up the rules refused to load.

This is the third time I've been bit badly by an issue relating to gitsyncing the IPv6 code and I've had enough. I don't blame you guys. Anyway, I removed all the IPv6 options from my config, rebooted, edited the version file to make the updater think I had one of the 2.0 RCs, and then told it to auto-update me to 2.0-RELEASE and all is well. I'll try IPv6 again when pfSense moves to 2.1.

databeestje · Oct 30, 2011, 9:55 PM

Yeah, that was unfortunate, to be fair though, the same thing broken in the 2.0 branch for our 2.0.1 builds. But nobody has snapshots of those.

It's fixed by now though. If you stick to the snapshots we post in file.pfsense.org/jimp/ipv6 you should be fairly safe since those are a bit more tested then straight out of the git tree.

Atleast you already know the deal with IPv6 by now which is win, spread the gospel ;-)

jasonlitka · Oct 31, 2011, 8:03 PM

I've still for a couple Alix boxes sitting around here, maybe I'll try IPv6 on one of those again soon in a test environment. I'm done on my primary box at home though until it goes gold. My main computer bought it during the same power outage this past weekend and it was hell trying to get the thing working without a working internet connection for research…

EDIT: Also, file.pfsense.org/jimp/ipv6 is a bad link, I think you meant "http://files.pfsense.org/jimp/ipv6/"