Project

General

Profile

Issue #3468

[site2site IKEv2] Route rule 220 assigns my own gateway instead remote peer

Added by Samuel Arellano about 1 month ago. Updated about 1 month ago.

Status:
Feedback
Priority:
Normal
Assignee:
-
Category:
-
Affected version:
5.6.2
Resolution:

Description

Hi, I'm trying to deploy a site-to-site connection. It is established and my IPSec peer can ping remote subnet, but from remote subnet they can ping local IP of my peer but any other host in subnet is unreachable, also, any host in my subnet can't ping remote subnet. Reading documentation I was following this guide ( https://www.strongswan.org/testing/testresults/ikev2/net2net-psk/ ) which is pretty much what I want to achieve and I noticed that routing rule 220 assigns ( via <IP> ) the IP of the remote peer, but in my case my 220 rule assigns the IP of my gateway.

Is this a misconfiguration? where can I modify this behaviour?


$ ip -4 a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    inet 162.209.99.34/24 brd 162.209.99.255 scope global eth0
       valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    inet 10.176.1.20/18 brd 10.176.63.255 scope global eth1
       valid_lft forever preferred_lft forever

$ ip r s t 220
192.168.1.0/24 via 162.209.99.1 dev eth0 proto static src 10.176.1.20
$ ip r
default via 162.209.99.1 dev eth0 proto static 
10.176.0.0/18 dev eth1 proto kernel scope link src 10.176.1.20 
10.176.0.0/12 via 10.176.0.1 dev eth1 proto static 
10.208.0.0/12 via 10.176.0.1 dev eth1 proto static 
162.209.99.0/24 dev eth0 proto kernel scope link src 162.209.99.34

History

#1 Updated by Samuel Arellano about 1 month ago

more info:

Remote peer is a Fortinet device.
My local peer is in Rackspace cloud.

And my statusall looks like this:

Status of IKE charon daemon (strongSwan 5.6.2, Linux 4.15.0-101-generic, x86_64):
  uptime: 26 minutes, since May 28 14:29:02 2020
  malloc: sbrk 1622016, mmap 0, used 626864, free 995152
  worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0, scheduled: 2
  loaded plugins: charon aesni aes rc2 sha2 sha1 md4 md5 mgf1 random nonce x509 revocation constraints pubkey pkcs1 pkcs7 pkcs8 pkcs12 pgp dnskey sshkey pem openssl fips-prf gmp agent xcbc hmac gcm attr kernel-netlink resolve socket-default connmark stroke vici updown eap-mschapv2 xauth-generic counters
Listening IP addresses:
  162.209.99.34
  2001:4802:7800:1:be76:4eff:fe20:c2
  10.176.1.20
Connections:
     net-net:  162.209.99.34...190.121.1.70  IKEv2
     net-net:   local:  [162.209.99.34] uses pre-shared key authentication
     net-net:   remote: [190.121.1.70] uses pre-shared key authentication
     net-net:   child:  10.176.0.0/18 === 192.168.1.0/24 TUNNEL
Security Associations (1 up, 0 connecting):
     net-net[1]: ESTABLISHED 26 minutes ago, 162.209.99.34[162.209.99.34]...190.121.1.70[190.121.1.70]
     net-net[1]: IKEv2 SPIs: 42aa81221c434f9f_i 878dcf57f58180e3_r*, pre-shared key reauthentication in 23 hours
     net-net[1]: IKE proposal: AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_2048
     net-net{2}:  INSTALLED, TUNNEL, reqid 1, ESP SPIs: c6abfa4b_i 4ba6a963_o
     net-net{2}:  AES_CBC_256/HMAC_SHA2_256_128, 0 bytes_i, 0 bytes_o, rekeying in 3 minutes
     net-net{2}:   10.176.0.0/18 === 192.168.1.0/24

#2 Updated by Tobias Brunner about 1 month ago

  • Status changed from New to Feedback

I noticed that routing rule 220 assigns ( via <IP> ) the IP of the remote peer, but in my case my 220 rule assigns the IP of my gateway.

That's exactly as it should be. In the test scenario the hosts are directly connected.

Please read ForwardingAndSplitTunneling.

#3 Updated by Samuel Arellano about 1 month ago

Tobias Brunner wrote:

I noticed that routing rule 220 assigns ( via <IP> ) the IP of the remote peer, but in my case my 220 rule assigns the IP of my gateway.

That's exactly as it should be. In the test scenario the hosts are directly connected.

I see, so it's not wrong at all.

Please read ForwardingAndSplitTunneling.

I will...

Also available in: Atom PDF