not sure if im supposed to manually create an SA for the bearer traffic (between 192.168.0.0/22 and 192.168.255.0/24) to go along with the SA I created between the BGP peer IPs? I noticed I was not getting any encrypted traffic out my wan interface when trying to ping from 192.168.0.0/22 to 192.168.255.0/24, so I did add an additional SA between 192.168.0.0/22 and 192.168.255.0/24 in pfsense, and now I do see encrypted traffic when I ping, but still no routes in netstat -nr, so this leaves me a bit concerned as to whether/not Ill have good BGP routing resilience in the first place...

@tsho_admin Yes, you need to add 10.2.1.0/24 to the phase 2 on site A as well, so that the IPSEC tunnel is aware of the addresses for the OpenVPN network.

no problem glad you got it sorted.. See how short threads can be when decent amount of info and drawing to show how all connected given ;) Wish more posts were like yours for detailed information when asking for help.

@caltommo said in HELP APPRECIATED** 3G/4G Modem as WAN Interface?!: Is there an alternative? It doesn’t have to be 100% reliable ... You mean as unreliable as your main internet connection? Be prepared that it fails the exact moment your regular connection is down already. There is no place for cheap when you need a backup for failsafe operation. Or vice versa, if it has to be cheap then it's not needed. I had positive results with this device https://www.amazon.co.uk/D-Link-DWR-921-Router-abnehmbare-Antennen/dp/B00BN36NMM

I managed to fix this. Annoyingly I was selecting the wrong physical NIC for the virtual switch...

Your route is 192.168.1.0/32 That is never going to work.. But since its your default it should work.. So your remote client knows to get to 192.168.42/24 it needs to go down the tunnel. Then your VPN devices knows how to get to this as well via pfsense. And your allowing the firewalling? And your not natting at pfsense. Or are you port forward and having your client try and talk to pfsense wan IP 172.17.20.98 So are you still having issues.. If so going to need the details ask about.

@viragomann Thanks a lot! I find the solution: for changing gateway there are have to be two rules for VLAN: Access to local VLANS via Default gateway (x.x.x.254). Access outdoor where you can change gateway ( GW to internet ) [image: 1529232793327-screen-shot-2018-06-17-at-13.46.26-resized.png] Problem was occurred because seting not default gateway not working as expecting. When your set custom GW (not default) at some VLAN your VLAN can not access to other VLANs via it. When set Default GW pfSense know which route to go to access other VLANS and even go outdoor for internet access. So first rule sase how to access VLANs indoor, and second sase how to go outdoor. Thanks very much! Problem solved! Now I understand how to setup failover

I read those docs. They seem simple enough. I tried creating firewall rules and they didn't do anything. I have tried various rules this morning and none of them did anything at all. Can you explain how I would setup rules to allow traffic from only one VLAN to go through my failover interface? Thanks!

There are automatic NAT rules that get put in place to mask VPN client networks on the way out. You can override that: Navigate to Firewall > NAT, Outbound tab Switch to Hybrid Outbound NAT mode and save Click Add to top (upward pointing arrow) Check "Do Not NAT" Interface=WAN, protocol=any Set the source to your public subnet (e.g. 2.2.2.0/29) Destination=Any Description="Do not NAT OpenVPN public clients" Save, Apply Changes

That bug seems to be unrelated. At least to the packet capture above. It's not failing to NAT traffic there just opening a stream to the wrong location. The only place it could have got that from (unless it's hard coded into the server) is from the client. Steve

No. That capability does not exist. You will have to manually monitor and disable the gateway when the cap is reached.

Wanted to provide an update to my own thread - after doing research it seems that OSPF will not create an automatic source/outbound NAT. So, it would seem that the "fix" would be to create automatic outbound NAT AND manual (hybrid mode), but this kind of defeats the whole point of OSPF. I could do a summary NAT, but then still, the benefit of OSPF would not be fully realized. Hrm.

When that is the case it is customary to duplicate the steps to repeat the condition and report it, so the developers have something to work with regarding your specific set of circumstances. I understand it is a burden. Sometimes it is easier to just say, "it's a bug, fix it."

You only need an outbound NAT rule for that. Firewall > NAT > Outbound If your outbound NAT is in automatic mode switch to hybrid first. Then add a rule: Interface: IoT Destination: 10.10.30.10 (the cam) Translation address: Interface address. Rules to allow access have to to be add to the interface where the connections come into pfSense, here it is the core.

https://www.netgate.com/docs/pfsense/nat/accessing-port-forwards-from-local-networks.html