After further testing I have determined that the VPN tunnel did not fail. I created a new tunnel to a different location. Connected the ipsec tunnel between the two locations and did a test ping to the pfsense server private ip address, (192.168.10.3) it works. Connected to the another host on the VPC network at DO and set its default gateway to 192.168.10.3 and able to ping it from the remote host of 192.168.0.2. The constant ping has been running for 2 hours now. But I did determine that when the initial site-to-site tunnel was connected, I lost communications to the public ip address of the pfsense host at DO from my local computer. (not part of the current VPN tunnel) And from the local VPN site, I cannot open the private ip address of the pfsense host through the vpn tunnel. https://192.168.10.3. But I can ping the host of 192.168.10.3 I have a setting wrong someplace. Any suggestions?

I had this same issue and what worked for me is creating a floating rule on the downstream PfSense to allow WAN to LAN connections. YMMW.

@trap16 it worked for me.

@viragomann Thank you for taking your time to respond. I'll see if I can make it work.

Is it possible that, like the 2.6 bug that was later fixed with a patch, which didn't let upd traffic pass through the captive portal, in this case it doesn't let udp traffic pass through the failover gateway?

@idanielluiz said in Direcionar o tráfego de um PC para navegação da minha WAN 2: @mcury como faço isso? [image: 1679326852322-d63da61b-df77-46b0-8f0b-d46b962f4c72-image.png] Só clicar na mãozinha rsrs

@steveits I may be interested in knowing more. My ATT router has a 5G port that is unused, but only 1 of the 2 routers has 5G capability, the pfSense. The other router is a MikroTik, but none of it's eth ports have 5G. For clarity, my pfSense router has a 5G wan input, and 2 10G SFP+ ports as potential outputs. I wanted perfect separation at the WAN connection, but I could use the 5G ethernet port on the ATT machine and go to the pfRouter, then split the connection to a second router via SFP+ and then to a switch for VPN access via the 2nd SFP+. This would give me 5G all the way to each router, than separate LANs from there.

@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!