Please Disregard. I forgot to configure my NAT OUTBOUND.

So your policy routing and forcing traffic out wan 1?, because you have not failed over. So yeah how would you get to wan 2 IP something.. What are the rules on your lan - did you set a gateway forcing traffic out that gateway? https://docs.netgate.com/pfsense/en/latest/multiwan/policy-route.html#bypassing-policy-routing

I created one, this seems like it would be a useful feature: https://redmine.pfsense.org/issues/12077

@daddygo I thank you for the answer.

@miesje said in Dual WAN IP routing: I had to remove the dhcp gateway WAN02 from the WAN02 rule, to default. Didn't notice the gateway setting before. No, the gateway option in a filter rule is only meant for policy routing and that is mostly not wanted on incoming traffic.

@pete35 Windows firewall blocks SMB from outside it's own subnet by default..... Did you check that?

Ok that is a start. So you have a vpn to 192.168.4? You have another connection in this 192.168.4 network along with your wan? You are just routing without vpn at 192.168.4 router to 192.168.1? via this public IP? And this 192.168.4 network also has a wan IP in this /29 public network? I REALLY suggest you get with your company IT dept about adding a firewall to your site, especially since it seems they don't even allow you access to your sites router?

@disakos Take a look here.

@kiokoman Thanks, data-payload = 2 resolved issue with one of my WANs

@tharun518 Corrected it.

@dono96 said in Routing thru 2 pfsenses: add more clients and pfsenses Why do you think you need more pfsenses? There is no point to adding firewalls for the sake of firewalls.. You could have hundreds of vlans firewalled from each other with 1 pfsense. FTP is dead - only thing you should be looking to do with that protocol is not use it ;)

You would port forward ports 502-508 from lan 2 pfsense IP to 192.168.0.4, and also setup source natting (outbound nat) So that 192.168.0.4 thinks its coming from the pfsense 192.168.0.X IP. Now when 192.168.2.10 tries to talk to pfsense 192.168.2.x IP it would be sent to 192.168.0.4

@dan2112 The LTE connection can only be used for outbound traffic if there is any route defined to go over it. So if there is no route, no traffic. If you only want to use it for a dial-in VPN, you don't need to set it as gateway. Simply connect the LTE modem to a pfSense interface and fire up an OpenVPN server listening on this interface. You will also need a dynamic DNS for the LTE, so you can connect to the hostname when you need.

@townsenk64 said in Packet loss with multiple VPN clients: monitor gateway such as 8.8.8.8 or 1.1.1.1. These give exactly the results that the DNS server load gives, not so relevant, DNS servers are not designed to respond to ICMP, but I know this is often the only solution. (this is not the main objective with them = ICMP respons) f.e.: Neither SurfShark nor ExpressVPN gateway not respond to ICMP. (security question) Tracert...... and it will tell you what is the nearest upstream GW in your VPN tunnel that responds to ICMP I wouldn't think it's a "dpinger" issue, because it works for me and others. What I would do next: First check the parameters of the WAN-only with ISP connection (pls. heavy load the link, for example with this: https://speed.cloudflare.com/ or https://www.nperf.com/en/) I would take down all the VPN tunnels and bring them up one by one In the meantime, I would monitor the hardware CPU load, as OpenVPN is a single-threaded beast Step by step I would launch VPN tunnels, after you should see if doing so increases packet loss and CPU load BTW: What type of ISP connection do you have? (PPPOE, GPON, ADSL, etc)

Further investigation I issued the statement via shell usbconfig It then displayed: ugen0.1: <Marvell XHCI root HUB> at usbus0, cfg=0 md=HOST spd=SUPER (5.0Gbps) pwr=SAVE (0mA) ugen1.1: <Marvell EHCI root HUB> at usbus1, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE (0mA) ugen0.2: <HUAWEI Technology HUAWEI Mobile> at usbus0, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON (500mA) I then checked those devices: ls -l /dev/ugen* It then displayed: lrwxr-xr-x 1 root wheel 9 Jun 4 21:44 /dev/ugen0.1 -> usb/0.1.0 lrwxr-xr-x 1 root wheel 9 Jun 4 21:43 /dev/ugen0.2 -> usb/0.2.0 lrwxr-xr-x 1 root wheel 9 Jun 4 21:44 /dev/ugen1.1 -> usb/1.1.0 The USB device is on /dev/ugen0.2 but the Netgate device's PPP is only acknowledging /dev/cuau0 I also tried editing the file /etc/ppp/ppp.conf and tried to replace anything the says "cuau*" into "ugen*" to test if it is about the configurations. I rebooted the device and after it was on, Netgate still just recognizes /dev/cuau0 on the PPP lists and not /dev/ugen0.2 Do you guys know what could be done to solve this? Any hint or direction is much appreciated