Project

General

Profile

Issue #3553

Route-based VPN with vti interfaces and start_action = trap don't work

Added by Thomas Melde about 2 months ago. Updated 23 days ago.

Status:
Closed
Priority:
Normal
Category:
network / firewall
Affected version:
5.9.0
Resolution:
No change required

Description

Hello,

please, I need any hint what is wrong or if it generally don't work that way:

I try to use vti interfaces and expect to see VPN connection coming up with 'start_action = trap'. But it don't, it just happens nothing, no IKE etc.
It's not a general problem with vti interfaces, what works perfect is:
  • if I use 'start_action = trap' and start VPN connection with
    swanctl -i --child child1
    

    it is all ok, IKE, vti interface, traffic ... no problem
  • if I use 'start_action = start' also all ok, immediately connection comes up

But with 'trap' no chance. If I use the same configuration, without vti (simply without 'mark_in' and 'mark_out' in child config section) also 'trap' works now perfect.

My config:

connections {
   conn1 {
      local_addrs  = %any
      remote_addrs = 192.168.178.95
      local {
         auth = psk
         id = vti
      }
      remote {
         auth = psk
         id = db2
      }
      children {
         child1 {
            local_ts  = 10.10.10.0/24
            remote_ts = 192.168.2.0/24
            updown = /projects/vpn/vpn-server/_updown
            start_action = trap
            mark_in = 42
            mark_out = 42
        }
      }
      version = 2
      mobike = no
      reauth_time = 10800
   }
}

secrets {
   ike1 {
      id1 = vti
      id2 = db2
      secret = xxxxxxxx
   }
}

ipsec status:

Status of IKE charon daemon (strongSwan 5.8.0, Linux 4.15.0-96-generic, x86_64):
  uptime: 39 seconds, since Aug 27 13:49:19 2020
  malloc: sbrk 2662400, mmap 0, used 493504, free 2168896
  worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0, scheduled: 0
  loaded plugins: charon rc2 md5 random nonce x509 revocation constraints pubkey pkcs1 pkcs7 pkcs8 pkcs12 pgp dnskey sshkey pem openssl fips-prf xcbc cmac attr kernel-netlink resolve socket-default farp stroke vici updown eap-identity eap-md5 eap-mschapv2 dhcp counters
Listening IP addresses:
  192.168.178.97
  fd73::2
  2003:ec:ef37:6600:a00:27ff:fea3:b5dc
  10.10.10.1
  fd10::1
Connections:
       conn1:  %any...192.168.178.95  IKEv2
       conn1:   local:  [vti] uses pre-shared key authentication
       conn1:   remote: [db2] uses pre-shared key authentication
      child1:   child:  10.10.10.0/24 === 192.168.2.0/24 TUNNEL
Routed Connections:
      child1{1}:  ROUTED, TUNNEL, reqid 1
      child1{1}:   10.10.10.0/24 === 192.168.2.0/24
Security Associations (0 up, 0 connecting):
  none

policy:

ip xfrm policy show
src 10.10.10.0/24 dst 192.168.2.0/24
        dir out priority 375424
        mark 0x2a/0xffffffff
        tmpl src 192.168.178.97 dst 192.168.178.95
                proto esp reqid 1 mode tunnel
src 192.168.2.0/24 dst 10.10.10.0/24
        dir fwd priority 375424
        mark 0x2a/0xffffffff
        tmpl src 192.168.178.95 dst 192.168.178.97
                proto esp reqid 1 mode tunnel
src 192.168.2.0/24 dst 10.10.10.0/24
        dir in priority 375424
        mark 0x2a/0xffffffff
        tmpl src 192.168.178.95 dst 192.168.178.97
                proto esp reqid 1 mode tunnel
src 0.0.0.0/0 dst 0.0.0.0/0
        socket in priority 0
src 0.0.0.0/0 dst 0.0.0.0/0
        socket out priority 0
src 0.0.0.0/0 dst 0.0.0.0/0
        socket in priority 0
src 0.0.0.0/0 dst 0.0.0.0/0
        socket out priority 0
src ::/0 dst ::/0
        socket in priority 0
src ::/0 dst ::/0
        socket out priority 0
src ::/0 dst ::/0
        socket in priority 0
src ::/0 dst ::/0
        socket out priority 0

Routing:

ip route
default via 192.168.178.2 dev eth0
10.10.10.0/24 dev eth1 proto kernel scope link src 10.10.10.1
192.168.178.0/24 dev eth0 proto kernel scope link src 192.168.178.97

Try to ping remote ts:

ping -I 10.10.10.1 192.168.2.1
PING 192.168.2.1 (192.168.2.1) from 10.10.10.1 : 56(84) bytes of data.
^C
--- 192.168.2.1 ping statistics ---
4 packets transmitted, 0 received, 100% packet loss, time 3083ms

Start connection manually:

swanctl -i --child child1
[IKE] initiating IKE_SA conn1[1] to 192.168.178.95
[ENC] generating IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) N(HASH_ALG) N(REDIR_SUP) ]
[NET] sending packet: from 192.168.178.97[500] to 192.168.178.95[500] (792 bytes)
[NET] received packet: from 192.168.178.95[500] to 192.168.178.97[500] (278 bytes)
[ENC] parsed IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) N(HASH_ALG) N(CHDLESS_SUP) N(MULT_AUTH) ]
[CFG] selected proposal: IKE:AES_CBC_128/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/ECP_256
[IKE] authentication of 'vti' (myself) with pre-shared key
[IKE] establishing CHILD_SA child1{2}
[ENC] generating IKE_AUTH request 1 [ IDi N(INIT_CONTACT) IDr AUTH SA TSi TSr N(MULT_AUTH) N(EAP_ONLY) N(MSG_ID_SYN_SUP) ]
[NET] sending packet: from 192.168.178.97[500] to 192.168.178.95[500] (320 bytes)
[NET] received packet: from 192.168.178.95[500] to 192.168.178.97[500] (224 bytes)
[ENC] parsed IKE_AUTH response 1 [ IDr AUTH SA TSi TSr N(AUTH_LFT) ]
[IKE] authentication of 'db2' with pre-shared key successful
[IKE] IKE_SA conn1[1] established between 192.168.178.97[vti]...192.168.178.95[db2]
[IKE] scheduling reauthentication in 10787s
[IKE] maximum IKE_SA lifetime 11867s
[CFG] selected proposal: ESP:AES_CBC_128/HMAC_SHA2_256_128/NO_EXT_SEQ
[IKE] CHILD_SA child1{2} established with SPIs c9bb76f0_i cad1fecb_o and TS 10.10.10.0/24 === 192.168.2.0/24
[CHD] updown: net.ipv4.conf.ipsec1.disable_policy = 1
[CHD] updown: net.ipv4.conf.ipsec1.rp_filter = 0
[IKE] received AUTH_LIFETIME of 9867s, scheduling reauthentication in 8787s
initiate completed successfully

Now ping again:

ping -I 10.10.10.1 192.168.2.1
PING 192.168.2.1 (192.168.2.1) from 10.10.10.1 : 56(84) bytes of data.
64 bytes from 192.168.2.1: icmp_seq=1 ttl=64 time=1.61 ms
64 bytes from 192.168.2.1: icmp_seq=2 ttl=64 time=1.39 ms
64 bytes from 192.168.2.1: icmp_seq=3 ttl=64 time=1.19 ms
64 bytes from 192.168.2.1: icmp_seq=4 ttl=64 time=1.32 ms

Like mentioned, my question is not directly about how to configure vti, it's solely about how to initiate IKE session with related traffic if VPN config using 'mark_in' and 'mark_out'.

Best regards and thans in advance,
Thomas

History

#1 Updated by Tobias Brunner about 2 months ago

  • Status changed from New to Feedback

I try to use vti interfaces and expect to see VPN connection coming up with 'start_action = trap'.

Not sure if VTIs work with trap policies (they do with XFRM interfaces, though, or just without any interfaces at all). But for having even the slightest chance of working, you need to route traffic to the VTI (I don't see such a route). Also see RouteBasedVPN for basics.

If I use the same configuration, without vti (simply without 'mark_in' and 'mark_out' in child config section) also 'trap' works now perfect.

The marks have nothing to do with VTIs (i.e. you can use marks just fine without any special interfaces and that will also work with trap policies).

Like mentioned, my question is not directly about how to configure vti, it's solely about how to initiate IKE session with related traffic if VPN config using 'mark_in' and 'mark_out'.

Again, the marks have nothing to do with VTIs. And to match a policy with marks, you obviously have to mark the traffic (which is what the VTI does if one is used, otherwise it has to be done manually via Netfilter before the traffic hits the policies).

#2 Updated by Thomas Melde about 2 months ago

Tobias Brunner wrote:

Not sure if VTIs work with trap policies (they do with XFRM interfaces, though, or just without any interfaces at all). But for having even the slightest chance of working, you need to route traffic to the VTI (I don't see such a route). Also see RouteBasedVPN for basics.

Tobias thanks for your answer. My problem is only the connections.<conn>.children.<child>.start_action = trap setting.
I expect to see starting IKE handshake after a ping to remote ts. Exactly like it is working without VTI interfaces. This is before any VTI interface exists, and therefore before any route to VTI interface is set.
I create VTI interface in _updown script, set the route, it's all working perfect, no problems.
Only the start_action = trap don't work.

Not sure if VTIs work with trap policies

Yes this is exactly my question. Not really "how" but "if" , can I be shure that they sould work ?

#3 Updated by Tobias Brunner about 2 months ago

This is before any VTI interface exists, and therefore before any route to VTI interface is set.

So how would you expect that to work?

I create VTI interface in _updown script, set the route, it's all working perfect, no problems.

That obviously doesn't work with trap policies (see updown).

#4 Updated by Thomas Melde about 2 months ago

Ah ok, even the very first "trap triggering" packets already need the mark's.
Can be done using iptables or creating the vti. Like you said in your first answer.
Thanks :-)

#5 Updated by Tobias Brunner about 2 months ago

Ah ok, even the very first "trap triggering" packets already need the mark's.

Yep, the whole point of putting marks on policies is that only marked packets match them :)

#6 Updated by Tobias Brunner 23 days ago

  • Category set to network / firewall
  • Status changed from Feedback to Closed
  • Assignee set to Tobias Brunner
  • Resolution set to No change required

Also available in: Atom PDF