Order of routing
-
@tinfoilmatt
I haven't used outbound NAT in this correlation and it shouldn't be necessary in this case.
The TO wants to route out traffic to a certain destination to the WAN gateway. There should be already an existing rule on the WAN (automatic) which handles this traffic. -
@viragomann said in Order of routing:
There should be already an existing rule on the WAN (automatic) which handles this traffic.
If OP wants to keep bashing their head up against your initial advice (i.e., "routing is done in the kernel and overrules any other routes"), sure.
Strong suggestion to use "Manual Outbound NAT rule generation. (AON - Advanced Outbound NAT)" radio under
Firewall / NAT / Outbound, @Lillefjer, and ensure desired config. What you want to do should be possible with a translation rule on the IPsec interface. -
@tinfoilmatt said in Order of routing:
What you want to do should be possible with a translation rule on the IPsec interface.
Translating to which IP address?
An IPSec tunnel has no IP at all.@Lillefjer said in Order of routing:
have a VPN tunnel with a remote network 10.0.0.0/8, but I have a single host 10.10.10.248 that I would like to have out of the WAN interface
So 10.10.10.248 shouldn't be routed over the IPSec tunnel, but to the WAN gateway.
Normally pfSense has an automatically generated outbound NAT rule on the WAN, which will translate this traffic to the WAN address.
So why do you think, that there is any need for a manual rule? -
@viragomann I agree on the 10.0.0.0/8 but that is how the customer wants it. They have a huge network and need to reach our servers.
This pfsense firewall is behind our datacenter firewall, so this firewalls WAN is connected to the datacenter firewall and should be able to connec to 10.10.10.248 which is our Opsview monitor host. But the IPSEC tunnel forces all 10.0.0.0/8 traffic our the enc0 interface.
Another strange thing is, i have tried to make a outbound nat rule on the LAN interface, saying that traffik FROM 10.10.10.248 should be translated to the firewalls LAN adress. So the server see the firewall LAN address as src host and not the 10.10.10.248. But that didnt work either. I could see the trafik inter WAN interface but then i just disappered in the firewall.
Tomorrow i will recap all the thing i have tried so far and post it here
-
@viragomann said in Order of routing:
Translating to which IP address?
An IPSec tunnel has no IP at all.Source 10.10.10.248/destination 'any' translated to 'LAN Address', perhaps? Would that not get those packets off the IPsec VTI and onto the LAN interface—and keep state? Not saying it's not kludgy, but like you said, we're wrestling with the kernel here!
Plus there's a couple other ways I could think of to try there, with manually created rules (and no pesky hidden, automatic rules to confound me).
@viragomann said in Order of routing:
So why do you think, that there is any need for a manual rule?
Some administrators prefer more granular control and/or are more paranoid than others.
-
@Lillefjer Could try creating a VIP (
Firewall / Virtual IPs) on the LAN interface, and translate 10.10.10.248-sourced traffic's destination to it. Again, like you're aware—just to get those 10.10.10.248-sourced packets out of the tunnel.Now we're getting really kludgy, though.
Could also try to translate to WAN address to make sure you're bypassing LAN interface's routing table in case it sees that 10.0.0.0/8 route. Just make sure you then also include 10.10.10.248 in the source addresses that are translated to WAN address when egressing WAN interface outbound (i.e., 'standard' outbound NAT).
-
@Lillefjer There is a MUCH simpler solution - simply bypass (exclude) that IP from the IPsec policy based route. That will cause it to follow the standard routing on your pfSense (leave on the expected interface).
It’s a MUCH overlooked feature in the VPN -> IPSEC -> Advanced tab. Simply enter the IPs to exclude from the policy and restart IPsec, and you are done :-)
Love the no fuss of using the official appliances :-)
-
@keyser Daaaaang! Would 'up' that twice if I could, lol.
Please say you hadn't yet seen this setting, OP!
-
@keyser OMFG!!
It worked! The server in side (10.38.24.100) can ping the Opsview server a 10.10.10.248 via the WAN internface and not the IPSec.
Why didnt i know that filter?!!
I think that will solve all my problems.
-
@Lillefjer Just happy to help
-
Everything works now.
Thanks alot everyone :)
-
@keyser said in Order of routing:
There is a MUCH simpler solution - simply bypass (exclude) that IP from the IPsec policy based route.
Wow. Didn't know this as well.
Thx.
