My router has a WAN IP configured, let’s say 1.2.3.4, as well as a local IP on a VLAN interface, 10.10.0.1/24.
I have configured an IPSec VPN policy from 10.10.0.0/24 to 10.20.0.0/24. This VPN establishes a connection via 1.2.3.4 and works fine.
However, I have to manually define the Source IP:
/ping 10.20.0.1
will fail with a net unreachable response from the WAN router. Packet Capture shows that it uses 1.2.3.4 as the source IP.
/ping 10.20.0.1 src-address=10.10.0.1
succeeds.
How can I configure the router to always use 10.10.0.1 when initiating a connection from local to 10.20.0.0/24? I tried adding a route with a preferred source, but this does not seem to work.
Thanks for your response! I just double-checked, and I don’t have any masquerade or NAT rule that could be impacting this. Any other reason this could happen?
It is actually correct and the same when you run BGP or OSPF the tik itself has no idea what source IP to use.
The networks either end will work correctly it’s only a problem on the tik itself
Specifically the two services you can’t set source IPs for being dns and ntp won’t work much to my angst.
I am running BGP on the router, yes. The main problem I have with this is that I can’t set up log forwarding via the management interface because it just refuses to use the internal IP for the syslog. Any idea how to work around that? Whitelist the public IP on the log collector?
How can I configure the router to always use 10.10.0.1 when initiating a connection from local to 10.20.0.0/24? I tried adding a route with a preferred source, but this does not seem to work.
well.. if you knew how to read routing tables - you don’t need extended switch for pings. your 10.10 and 10.20 networks should have a shared gateway network between them.
what you have now is a split routing. your ping went outside to the internet. not going inside the tunnel.
@wiseroute Can you be a bit more specific as to what you think the problem is? I understand that the ping went to the internet instead of the tunnel. That’s what I’m asking how to fix.
It’s an IPSec policy, so how are routing tables going to help me? I just added it in case it might help, but as expected, it did nothing. Besides, from what I understand, policy based routing is being ignored in conjunction with IPSec anyways due to the way IPSec hooks into the packet flow.
The thing is that IPsec traffic selectors do not substitute the regular routing process, they just override its result if it matches them. In another words, the regular packet routing and firewall processing, including eventual src-nat, must always take place first, and only then the final result (packet) is inspected by the IPsec traffic selectors. If the regular routing finds no route for the packet, or if it finds a blackhole one, the packet is dropped even if it matches some IPsec traffic selector.
So if the route for a given packet goes through a WAN interface and there is a source nat rule (src-nat or masquerade) that matches on that WAN interface, the source address of the packet gets changed and doesn’t match the traffic selector any more.
Each route has a source address associated to it, which is assigned to packets the router itself is sending. Unless explicitly set otherwise (using the pref-src parameter of the route), it is the address associated to the interface through which the packet is sent. There are nuances if multiple addresses are attached to the same interfaces.
