Source NAT with Secondary WAN IP for IPSec Tunnels

General questions
, ,
1

Hi!

I have a VyOS 1.3-rolling-202006081325 with two WAN addresses, and I am trying to setup IPSec VPNs using the secondary IP as peer, local address and also also local prefix on these tunnels.
I noticed that IPsec is still being sent using the primary address, and sometimes source nat is not working for remote prefixes, leading me to create source nat for the IPSec remote peer, and source nat for the remote prefixes.
Source NAT forcing outgoing requests to the remote peer seems to work, without rebooting the VyOS, but source nat for the remote prefixes (changing the source address to the remote prefixes to into the secondary VyOS public address), does not always work, and I see with tcpdump, the primary address is still being used.
Please what am I doing wrong or how can I fix this?

2

Can you share your configuration, with a clear example on what is going on, and what do you expect | need | want?

3

You’d probably need /32 route for remote ipsec peer pointing to GW on WAN2.

4

Certainly.

I have two IP addresses on the WAN:

eth2             xxx.xxx.84.15/31                  u/u  WAN
                 xxx.xxx.40.5/32

I want to use xxx.xxx.40.5/32 for local-address and local-prefix for a series of IPSec tunnels.
For example:

 authentication {
     id xxx.xxx.40.5
     mode pre-shared-secret
     pre-shared-secret xxxxxx
     remote-id xxx.xxx.0.5
 }
 connection-type initiate
 ike-group ike-with-remote
 local-address xxx.xxx.40.5
 tunnel 0 {
     esp-group esp-with-remote
     local {
         prefix xxx.xxx.40.5/32
     }
     remote {
         prefix xxx.xxx.0.23/32
     }
 }
 tunnel 1 {
     esp-group esp-with-remote
     local {
         prefix xxx.xxx.40.5/32
     }
     remote {
         prefix xxx.xxx.0.21/32
     }
 }

I expected that, I should not need to do any special configuration in order to have the secondary IP be sent as ike and esp source address.
But for some tunnels and remote prefixes, the primary address is used.
So I worked around this by SNATing any traffic to the remote sides (peer and remote prefixes) to be the secondary IP.

show nat source rule 62| strip-private
 description "to with-remote peer xxxxx.tld"
 destination {
     address xxx.xxx.0.5
 }
 outbound-interface eth2
 source {
 }
 translation {
     address xxx.xxx.40.5
 }


show nat source rule 68| strip-private
 description "to with-remote prefix xxx.xxx.0.23"
 destination {
     address xxx.xxx.0.23
 }
 outbound-interface eth2
 source {
     address xxx.xxx.0.0/16
 }
 translation {
     address xxx.xxx.40.5
 }

 show nat source rule 69| strip-private
 description "to with-remote prefix xxx.xxx.0.21"
 destination {
     address xxx.xxx.0.21
 }
 outbound-interface eth2
 source {
     address xxx.xxx.0.0/16
 }
 translation {
     address xxx.xxx.40.5
 }

But despite this, traffic doesnt nat in some cases, and as a consequence, does not onboard the tunnel.
Wondering what I can do to fix it.
Apologies for any ambiguities, I hope I have explained the situation better.

5

food for thought: (this is how I think it works in Linux)
With IPSEC config, you specify your local source address, for example WAN2.
The route table still decides which outgoing interface to use (which can be the other interface WAN1 !)
The masquerade rule on WAN1 can alter your source IP (if there is no existing entry in the NAT table)
If the other side initiated the connection, the NAT table will be populated with an entry without translation.
The tunnel can work with triangular routing, where you send on WAN1 , and receive on WAN2 (if ISP allows spoofing)

6

OK but without the WAN2 as the source, the other end isnt accepting IPSec traffic.
Is there some command I can run to reset routing tables so it doesnt have this patchy behaviour, where some use WAN2 and some dont?

7

To fix in main route table: Add /32 routes towards ipsec peers on correct gateway.
Also, add routes for remote ipsec subnet (/24 in lot of cases) too.

But that won’t help when you have 2 tunnels to the same remote peer (like in failover)
To make linux automatically use correct interface when source IP = Wan1SRC or WAN2SRC requires PBR for locally generated packets. Not sure if load-balancer auto-creates such settings.

8

Ok will explore that, thank you. However a reboot seems to have helped a lot.