@johnpoz Sticks and stones may break my bones but there will always be an end-user face-palming me to my doom... ;)

Still stupid I totally disregarded this possibility! :)

@dhonz15
The screen only shows pings to the Globe gateway, which is replying correctly, as we already knew. So no news from that.
You should ping a public IP like 8.8.8.8 and enter this IP into the host filter box in the capture. So that you only get packets to or from that IP in the log.

@kdv666 said in How to filter wan output through linux box:

command line options 1 to create the interface, and 2 set the address.

Neither of which would set up the firewall rule on the interface.. As have stated - when you create a new interface there is no firewall rules. So no you wouldn't be able to ping it until you create a rule on the interface to all that.

There is ZERO reason to ever have to create a route to a network that an interface is attached too..

Pfsense not really from cmd line sort of box - you should just go to the gui and assign the interface and enable it put an IP on it and set the firewall rule(s) on the interface.

@hellschicken
On the homelab pfSense assign an interface to the respective OpenVPN instance, if you didn't already.
Then you will get a firewall rule tab for this interface. Add a rule for allowing the access from the remote site to this interface.
Remove the rules from the OpenVPN tab or at least modify existing rules so that they are not applied to the incoming traffic from the production site.

Make sure you have the Don't pull routes option checked in your OpenVPN Client configuration:
pfSense_Dont_pull_routes.png

-Rico

Hi folks,

I came across a very similar problem with a Netgate pfSense running version 21.05.01 and a Multi WAN setup [DSL as WAN1 (Tier1) and 4G router on Opt1 as WAN2 (Tier2)] using gateway groups for automatic failover.

Server side: CentOS7 with OpenVPN 2.4.11-1.el7 Client side: pfSense BSD with OpenVPN 2.5.2

The situation was as follows:

OpenVPN site-to-site connection was successfully established between server (CentOS) and client (pfSense) ping FROM server TO pfsense worked fine Once traffic was sent from pfsense to the server VPN, the connection immediately dropped, 100% reproducible

I played around with different compression settings and stuff but nothing really helped.

However, the final solution to reconfigure the OpenVPN from TCP to UDP.

Hope that helps someone in the future. :)

@lakeworthb ok I seem to have fixed it by setting "Disable Gateway Monitoring Action" in the VPN gateway. Why did I need to?

@djmaxx007 See policy routing

Hmm... should I have asked this question in a different category or does my question just make no sense? Seriously not sure what's wrong with my configuration. Has anyone else here managed to route traffic through different WANs based on destination domain?

@johnpoz Ahh. Thank you so much. It's amazing how little some service techs actually understand. That perfectly solved my problem.

@johnpoz said in Pfsense Routing to cisco 4321:
> you would create the new interface give it the IP 172.16.0.2/30 this one i know how to do it on pfsense.

You have zero need for a /24, but sure you could use it that if you want. But 30 is all you need. thanks for this.
%(#ff0000)[Create a gateway under routing to 172.16.0.1
%#ff00000)[Then create a route for 192.168.1.0/24 using that gateway..
Create any firewall rules on the 172.16.0.2 interface that you want to allow. if no rules then 172.16.1/24 could talk to 192.168.1/24 but 192.168.1/24 could not create conversations to 172.16.1/24
You would then need a route on cisco pointing to 172.16.0.2 for 172.16.1/24]]

sorry this steps i dont know how to create it on pfsense and on the cisco router
sorry im new to pfsense and routing to cisco. your help is really appreciated.

@jnelson well use your existing networks as the transit. And move your actual network to something else 192.168.5/24 on one side and 192.168.2/24 on other for example..

If you have no control over what network they use. Problem is you might have routing problems on their devices. But why can you not get with who manages the mpls routers to fix the problem.

Your going to have issues when device sends their syn,ack back to their gateway (pfsense) and pfsense never saw the syn to open the state.

The correct setup for what you have there is with transit networks.

As to routing on hosts, yeah you would need a route on the client that says hey you want to talk to 192.168.1/24 send it to mpls router at 4.1 vs pfsense at 4.254.

And on the other end your app server would need route to 4/24 to send it to 1.254 vs pfsense 1.1 address.

Problem with such a setup is you loose firewall between your networks.. I would really suggest you get with who manages the mpls to correct the setup. They should have no problems changing the ips to some new transit networks and fixing the routing. If they are currently using your pfsense IPs on each end as default.. Then you could change your networks and use the existing 4/24 and 1/24 networks as the transit networks.

@qfixxx said in Basic dual WAN policy-based routing setup doesn't work:

have to debug what other URLs/IPs maybe involved in subsequent calls to watch.spectrum.net

Yeah that can be PITA ;)

A sniff of all the traffic when force all its traffic out the correct gateway and it works can be helpful.

@johnpoz Thanks for the notification: the DNS, at least, should now be working.