@kruglerd So WANGW is your WAN2 gateway? If pfSense allows access to go out there must a rule be responsible. So to check out which rule is passing the traffic out, enable logging in all your rules coming in considerations (don't forget interface group and floating), initiate a traffic and check the firewall log.

@derelict Yes, I had outbound NAT configured. I'm embarrassed to admit that I neglected to check the firewall rules - The default allow all rule only matched packers sourced from the LAN subnet, not any subnet behind the LAN interface. All is working now. Thank you for your time!

@viragomann said in 2 routes with same destination ... is it possible?: netstat -x Yes I'm logging to an external syslog server, and I export netflow too with softflowd target to the same external server. In my systems logs I always got some error like that : softflowd 738 Unable to export flows syslogd - sendto: No buffer space available You think the problem is related with the target external syslog server? Can it cause some problem to my OpenVPN server to my sites? Here's what netstat -x give me : Shell Output - netstat -x Active Internet connections Proto Recv-Q Send-Q Local Address Foreign Address R-MBUF S-MBUF R-CLUS S-CLUS R-HIWA S-HIWA R-LOWA S-LOWA R-BCNT S-BCNT R-BMAX S-BMAX rexmt persist keep 2msl delack rcvtime tcp4 0 0 Pfsense-SiteA.https 192.168.1.99.49271 0 0 0 0 65700 65700 1 2048 0 0 525600 525600 0.00 0.00 7150.54 0.00 0.00 0.35 udp4 0 0 192.168.254.1.27723 192.168.254.2.2055 0 0 0 0 42080 57344 1 2048 0 0 336640 458752 udp4 0 0 192.168.254.1.37894 192.168.254.2.2055 0 0 0 0 42080 57344 1 2048 0 0 336640 458752 udp4 0 0 Pfsense-SiteA.syslog *.* 0 0 0 0 0 57344 0 2048 0 0 0 458752 udp4 0 0 Pfsense-SiteA.snmp *.* 0 0 0 0 42080 57344 1 2048 0 0 336640 458752 I dont know how to interpret that result?

@mrjoli021 So really not clear, why the access worked from the WAN side though. But something to keep in mind.

Took this project up again this weekend. Wrong username - yep, I'm that guy. The fact that I could ping, nslookup etc. from the client cmd line threw me. Apologies all...

I have stopped the startup of a workplace in a different network segment via WOL and after a new installation of the workplace OS and after moving it to the same lan, the startup runs via a home automation component. Thank you all for the response.

@skilledinept No way I can think of. You can simply forward the traffic, but only with masquerading so that the destination sees your IP instead of the origin client.

@steveits clients are out in the internet Everything is working. I don't have any issues. The issue is that with this configuration i am losing public ips of clients on chat server I needs proposal for fixing this

I narrowed it to SMP issue. Reverting to 1 CPU isn't showing this behaviour.

Just reviving this topic if it worked ! thanks !

@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: [image: 1633882835356-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?