Messages

31

18.1 Legacy Series / outgoing NAT with interface_address uses carp ip

« on: February 15, 2018, 12:12:10 pm »

After upgrading to 17.x to 18.1.2, the outgoing NAT address translation doesn't work any more as expected.

I have outgoing nat configured to use the interface address on a CARP cluster, which used do use the physical ip address of each machine.
After the upgrade, outgoing traffic uses all VIF ip addresses randomly, making some sites' session handling nonfunctional.

32

17.7 Legacy Series / Re: outgoing CARP blocked

« on: February 11, 2018, 03:40:25 pm »

That patch, apparently, included in 18.1, doesn't fix my issue.
Despite pass-rules on any carp traffic on the interface and as floating rule, the backup won't receive carp packets until I disable fw on the master.

33

German - Deutsch / 18.1 CARP-Pakete werden gefiltert

« on: February 11, 2018, 03:19:26 pm »

Ich muß diesen Thread noch mal bumpen.
Auch nach Upgrade auf 18.1.2 immer noch das gleiche Problem: Am Backup kommen die CARP-Announcements am WAN-Interface nur an, wenn ich am Master die Firewall disable.

34

German - Deutsch / Re: 17.7.6 CARP-Pakete werden gefiltert

« on: November 02, 2017, 09:25:54 am »

Floating Rules sind leer, anhängend die WAN-Rules mit meinen Versuchen CARP-Verkehr zu sehen.

35

German - Deutsch / Re: 17.7.6 CARP-Pakete werden gefiltert

« on: November 01, 2017, 05:51:23 pm »

Hab Bogon Filter testweise abgeschaltet. Hatte den unschönen Effekt daß nach Config neuladen auf dem Master alle VIFs wegwaren, ich mußte CARP disablen und enablen um ihn wieder zum Laufen zu bringen. Backup steht dauerhaft auf disabled, da CARP ja nicht funktionstüchtig ist....

Bogon Filter abschalten macht keinen Unterschied, weiterhin CARP Announcements nur bei pfctl -d auf dem Master.

36

German - Deutsch / 17.7.6 CARP-Pakete werden gefiltert

« on: November 01, 2017, 01:33:04 pm »

Nach einem Update eines Firewall-Paars von 17.1.2 über 17.1.11 auf 17.7.6 funktioniert CARP auf dem WAN-Interface nicht mehr, da der Master zwar seine CARP-Announcements wie erwartet erzeugt, diese die Firewall aber nicht verlassen und der Backup daher meint übernehmen zu müssen.
Im Filterlog ist von CARP nichts zu sehen, die Pakete gehen aber sofort raus wenn die Firewall per pfctl -d abgeschaltet ist. ACCEPT-Rules helfen nicht.

Irgendein Hinweis wo das hängenbleiben kann?

37

17.7 Legacy Series / Re: outgoing CARP blocked

« on: October 25, 2017, 05:23:57 pm »

<deviating>
Just tried: defining an IP Alias on a CARP interface isn't possible since the interface dropdown lists only physical interfaces.
If there's another way to reduce VIFs, didn't try to re-use a VIF (which according to man carp should happen behind the scenes), I'd love to know.
</deviating>

I didn't see blocked packages when filtering protocol=112 or protocol=carp, or blocked packages originating from the WAN interface. Still, they're dropped...

38

17.7 Legacy Series / outgoing CARP blocked

« on: October 25, 2017, 10:07:25 am »

I have a pair of opnsense routers with CARP which haven't been updated for quite a time. They were running 17.1.2 fine with 16 VIFs defined on the WAN interface (since it's still impossible to define IP aliases on a VIF), and some more on the LAN and DMZ sides.

After upgrading both machines to 17.7.6 the backup machine does't receive CARP announcements any more on the WAN interface (other interfaces are ok), so it will switch to master (on WAN only), messing up traffic badly.

Checking on the master, I still see CARP announcements generated on the WAN if, but apparently they are not passed out. As soon as I pfctl -d the firewall, I can see CARP arriving at the secondary as well; pfctl -e and announcements are lost again.

I added explicit rules on the WAN interface, allowing CARP from the firewall, and even any traffic from the firewall, no result.

Any hint how to get CARP working again? I'm non-redundant now, giving me a bad feeling after I had a kernel crash on the master lately.

Regards
Andreas

39

17.1 Legacy Series / carp/pfsync but connections interrupted

« on: June 22, 2017, 06:41:04 pm »

As far as I understand carp/pfsync, the backup firewall should take over the running sessions from the master more or less interruption free. On an heavy traffic tcp session, maybe some packets might need retransmission since there's a time gap between pfsyncs, but not more.

Apparently, this assumption is wrong. Even on a virtually idle system, connections are broken. I have a OS 17.1.8 pair (virtualized on Xen 4.4.1), machines are connected via 10GBit. The web server in the DMZ accesses the file storage via NFS4 tcp port 2049. When rebooting the master (for whatever reason, e.g. fw upgrade), the nfs mount might report a stale handle with no chance to recover but reboot the web server VM. I tried to demote the master to slave upfront, with persistence, and promote later back again, but this doesn't seem to help too much.

All other connections might break as well, but the nfs connection is really fatal.

Is there any means to make the carp/pfsync stuff work without breakage? Even a fancy solution improving the nfs breakage only would help. I've been observing this problem since pfSense 1.x/2.x/OS16.7 and it's still annoying.

Regards
Andreas

40

15.7 Legacy Series / Re: Gateway definition quirks

« on: December 23, 2015, 10:44:32 am »

Yes, the route is a host route.

I found this while "misusing" the gateway for monitoring connectivity, e.g. a remote gateway through an IPSEC tunnel. I defined a gateway with the LAN ip as gateway, and the remote gateway as monitoring ip (to ping through the ip tunnel, the source address must be local; ping would use the WAN address otherwise).
Actually, under some circumstances the icmp-redirect (probably auto-generated by the kernel) from this route can be plain wrong; I found a case when a route 80.x.x.x via 192.168.1.1 made the firewall emit "redirect 80.x.x.x to 80.x.x.x" on the 192.168 interface, advising workstations to go directly to 80.x.x.x. IIRC this occurred when 192.168.1.1 was a carp vif. I had to tune net.inet.ip.redirect=0.

I'd love an explicit option to use gateways just for monitoring purposes, i.e. with no route added, and not requiring the gateway to be locally reachable. This gateway would obviously be not be able to be part of a gateway group.

41

15.7 Legacy Series / Gateway definition quirks

« on: December 22, 2015, 07:40:58 pm »

I encountered this problem with pfsense (they say it's not bug...), and checked with opnsense now getting the same results:

The definition of a gateway implicitely creates a route via that gateway, if a monitoring ip is given. I found this unexpected, and would like to have a checkbox to disable this behaviour (it will create icmp-redirects unless disabled by kernel params).

Anyhow, if this gateway entry is disabled, the routing will still persist, which I'd call a bug. IMHO a disabled entry shouldn't have any side effect.

42

15.7 Legacy Series / Installation problem on Virtualbox with 512MB

« on: December 22, 2015, 07:26:02 pm »

I tried installing on Virtualbox for testing purposes, but the copying would fail at various positions. After trying different NIC and chipset settings, I found that increasing memory from 512MB to 1G did the trick. Apparently, 512MB is not sufficient to install (using 15.7.18-amd64).

Regards,
Andreas