@michmoor

Firewall A:

2.6.0-RELEASE][admin@pfSense0.lab.lan]/root: vtysh Hello, this is FRRouting (version 7.5.1). Copyright 1996-2005 Kunihiro Ishiguro, et al. pfSense0.lab.lan# sh running-config Building configuration... Current configuration: ! frr version 7.5.1 frr defaults traditional hostname pfSense0.lab.lan log syslog service integrated-vtysh-config ! password 123 ! ip router-id 10.10.10.1 ! interface em3 ip ospf area 0 ! router bgp 9990 bgp router-id 172.16.1.1 bgp log-neighbor-changes no bgp network import-check neighbor 192.168.1.23 remote-as 9991 neighbor 192.168.1.23 description pfsense1 neighbor 192.168.1.23 update-source 192.168.1.22 ! address-family ipv4 unicast redistribute ospf route-map allow-all no neighbor 192.168.1.23 send-community neighbor 192.168.1.23 route-map allow-all in neighbor 192.168.1.23 route-map allow-all out exit-address-family ! address-family ipv6 unicast redistribute ospf6 route-map allow-all neighbor 192.168.1.23 activate no neighbor 192.168.1.23 send-community neighbor 192.168.1.23 route-map allow-all in neighbor 192.168.1.23 route-map allow-all out exit-address-family ! router ospf ospf router-id 10.10.10.1 log-adjacency-changes detail neighbor 10.10.12.1 ! route-map allow-all permit 100 ! line vty ! end pfSense0.lab.lan#

Firewall B:

[2.6.0-RELEASE][admin@pfSense1.lab.lan]/root: vtysh Hello, this is FRRouting (version 7.5.1). Copyright 1996-2005 Kunihiro Ishiguro, et al. pfSense1.lab.lan# sh running-config Building configuration... Current configuration: ! frr version 7.5.1 frr defaults traditional hostname pfSense1.lab.lan log syslog service integrated-vtysh-config ! password 123 ! ip router-id 10.10.10.1 ! interface em3 ip ospf area 0 ! router bgp 9991 bgp router-id 10.10.10.1 bgp log-neighbor-changes no bgp network import-check neighbor 192.168.1.22 remote-as 9990 neighbor 192.168.1.22 description pfsense0 neighbor 192.168.1.22 update-source 192.168.1.23 ! address-family ipv4 unicast redistribute ospf route-map allow-all no neighbor 192.168.1.22 send-community neighbor 192.168.1.22 route-map allow-all in neighbor 192.168.1.22 route-map allow-all out exit-address-family ! address-family ipv6 unicast redistribute ospf6 route-map allow-all neighbor 192.168.1.22 activate no neighbor 192.168.1.22 send-community neighbor 192.168.1.22 route-map allow-all in neighbor 192.168.1.22 route-map allow-all out exit-address-family ! router ospf ospf router-id 172.16.1.1 log-adjacency-changes detail neighbor 172.18.1.1 ! route-map allow-all permit 100 set weight 1000 ! line vty ! end

@s3v3nd34dly51ns the LAN interface by default has an allow all rule. Other interfaces do not do default to deny all. What rules are on 192.168.55.0/24? Does the wireless device to which you’re trying to connect allow 192.168.55.0/24 in its firewall?

@viragomann Makes sense. Thank you!

@simpletechguy

All ok. I created an Alias with a list of domains where I need the router to go through the VPN. Created a static route where NETWORK this alias and selected VPN gateway. Did you do the same?

@denbir @denbir Glad you got it working, although I see no reason you shouldn't be able to when running in Proxmox.

@bdjackson https://docs.netgate.com/pfsense/en/latest/solutions/netgate-2100/opt-wan.html

which will need a port isolated:
https://docs.netgate.com/pfsense/en/latest/solutions/netgate-2100/configuring-the-switch-ports.html

Edit: you can also undo it if necessary by backing out the steps.

@cb831 Issue solved. Apparently my ISP had locked my WAN-MAC address for IPv6 communication but NOT for IPv4 communication.

When I set the WAN-MAC of my new firewall to the WAN-MAC of the old one - everything worked for IPv6.

For the info the uplink at my ISP is Juniper Networks and they had some problems before supporting especially FreeBSD based routers because the Juniper communication is doing some tricks that FreeBSD does not accept.

Months ago I had to add the tunable

net.inet6.icmp6.nd6_onlink_ns_rfc4861 To fix broken DHCP6 against Juniper 1

because Juniper DHCP6 answers from another IPv6 address than the edge IP.

CASE CLOSED

https://docs.netgate.com/pfsense/en/latest/recipes/modem-access.html

-Rico

@viragomann

Ha, that worked!

I also had to adjust the OpenVPN fw rule to allow the VoIP traffic from the road warrior tunnel network to pass through the HQ to Remote office tunnel.

Wonderful! Thank you muchly sir!

@viragomann it's already the case, on Site 1 et Site 2 i have already the routes
And if I disable NAT on Site 2, it doesn't matter, Site 1 still can't reach Site 3

Routes Site 1
48045dd9-271b-440e-a778-6facaabecbe2-image.png

Routes Site 2
007960ab-9e9f-47e3-8597-d8f18590593f-image.png

This guy explain perfectly everything

I made it work with the tutorial: https://www.youtube.com/watch?v=ulRgecz0UsQ&ab_channel=LawrenceSystems

@nmeth Of course I have now found the answer myself...

I did not have the "Skip rules when gateway is down" checkbox checked in the Advanced/Miscellaneous/Gateway Monitoring settings.

Information is at https://docs.netgate.com/pfsense/en/latest/config/advanced-misc.html#skip-rules-when-gateway-is-down

The new interface and routing through there resolved the slowness. Thanks for the help!

@viragomann

Site B Gateways
ec567ad8-ab56-434b-8ef3-5b696c41c567-image.png
I need to route via site1gw.

This is Site A Gateways
3b9632b9-bde1-4093-9e45-a1f45d336b57-image.png

Site A static route
56037d33-f0b5-4348-839e-0d24360d5ecb-image.png

Site B static route
ee1cbffe-7c37-4258-8a18-8141ca19d98c-image.png

@aiden21c it’s always the last place you look…

@keyser i dont use NtopNG

My current installed packages:
acme, cron, haproxy, openvpn, pfBlockerNG, snort, wireguard, zabbixagent

My current machine:
Supermicro Server 1HE
Intel(R) Xeon(R) D-2123IT
16GB DDR4
Intel SSD

2 different ISP WAN Interfaces
I have Failover Gateway Groups (trigger: Member down)

Update:
When my primary WAN is going down, the problem disapears.
If the primary is again enabled it gains 15ms...