@johnpoz There are no hosts on 10.43.0.0/24. This network is just used for the link between FW1 and FW2 via crossover cable (FW1 NIC Port 3 (IP 10.43.0.1) to FW2 NIC Port 2 (IP 10.43.0.2)). That VPN Box is eventually misplaced. OpenVPN is actually running on the OPNsense box. ... I may have just figured out what was missing in this very moment, after some more try & error and your response. I can ping FW1 from FW2. The reason seems to be that for the crossover cabling the option "This interface does not require an intermediate system to act as a gateway" needed to be enabled on the interface. I will give some further feedback after more testing. Edit: My bad, That was just a terrible mistake when testing. I still cannot reach FW2 from FW1 or vice versa. Do I need to setup a gateway?

BUMP

For anyone else who has this idea, I think it's a bigger pain than is warranted. I did more reading on libtorrent. The ports in the normal option menu of torrent clients are listen ports. When a connection is made and you seed a torrent, libtorrent uses dynamic outbound ports. You can set these as static, often using obscure options, but the libtorrent devs suggest not doing so as it can cause issues with establishing connections. So instead of doing all that and possibly having connection issues I will just be containerizing the torrent client on my server, using macvlan to give it a dedicated IP on my LAN, then routing that IP over the VPN interface using PBR. As for the other torrent clients on random computers on my LAN, it's probably best we stop using those and just use my server's client. Or we can use the VPN client on those computers.

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