[strongSwan] [SUSPECT EMAIL: No Reputation] Re: [SUSPECT EMAIL: No Reputation] multiple tunnels

Noel Kuntze noel.kuntze+strongswan-users-ml at thermi.consulting
Thu May 4 17:21:40 CEST 2017 

Nope. But you can disable the route installation from charon by setting charon.install_routes to no.
You can't use the _updown script to manage routes.

On 04.05.2017 17:17, Modster, Anthony wrote:
> Hello Noel
> 
> ? is there a way to  use _updown to set both routes (disabling Charon from setting the current route)
> 
> -----Original Message-----
> From: Noel Kuntze [mailto:noel.kuntze+strongswan-users-ml at thermi.consulting] 
> Sent: Thursday, May 04, 2017 4:12 AM
> To: Modster, Anthony <Anthony.Modster at Teledyne.com>; users at lists.strongswan.org
> Subject: [SUSPECT EMAIL: No Reputation] Re: [SUSPECT EMAIL: No Reputation] multiple tunnels
> 
> Hello Anthony,
> 
> I don't understand what you mean with that, but you could add a route to the remote peer with a higher MTU, if you can actually communicate over the other link with the IP on the other interface (the IP of another provider). If you can't do that, then this is not solvable.
> 
> On 04.05.2017 02:02, Modster, Anthony wrote:
>> Hello Noel
>> We were thinking of changing the created via for eth1.13 (adding matric info).
>> Then when ppp0 tunnel comes up, create another via for it.
>>
>> I think Charon does try to create a via for ppp0, but can't.
>>
>> -----Original Message-----
>> From: Noel Kuntze 
>> [mailto:noel.kuntze+strongswan-users-ml at thermi.consulting]
>> Sent: Wednesday, May 03, 2017 4:45 PM
>> To: Modster, Anthony <Anthony.Modster at Teledyne.com>; 
>> users at lists.strongswan.org
>> Subject: [SUSPECT EMAIL: No Reputation] Re: [SUSPECT EMAIL: No 
>> Reputation] Re: [strongSwan] [SUSPECT EMAIL: No Reputation] Re: 
>> [SUSPECT EMAIL: No Reputation] multiple tunnels
>>
>> Hello Anthony,
>>
>> As predicted, charon can't find an alternative network path:
>>
>> 2017 May  3 21:50:28+00:00 wglng-6 charon [info] 12[KNL] interface 
>> eth1.13 deactivated
>> 2017 May  3 21:50:28+00:00 wglng-6 charon [info] 05[KNL] 192.168.1.134 
>> disappeared from eth1.13
>> 2017 May  3 21:50:28+00:00 wglng-6 charon [info] 15[IKE] old path is 
>> not available anymore, try to find another
>> 2017 May  3 21:50:28+00:00 wglng-6 charon [info] 15[IKE] looking for a route to 76.232.248.210 ...
>> 2017 May  3 21:50:28+00:00 wglng-6 charon [info] 15[IKE] 
>> reauthenticating IKE_SA due to address change
>> 2017 May  3 21:50:28+00:00 wglng-6 charon [info] 15[IKE] 
>> reauthenticating IKE_SA sgateway1-gldl[1]
>> 2017 May  3 21:50:28+00:00 wglng-6 charon [info] 15[IKE] 
>> reauthenticating IKE_SA sgateway1-gldl[1]
>> 2017 May  3 21:50:29+00:00 wglng-6 charon [info] 05[IKE] sending DPD 
>> request
>> 2017 May  3 21:50:29+00:00 wglng-6 charon [info] 05[ENC] generating 
>> INFORMATIONAL request 23 [ ]
>> 2017 May  3 21:50:29+00:00 wglng-6 charon [info] 05[NET] sending 
>> packet: from 166.204.98.165[4500] to 76.232.248.210[4500] (96 bytes)
>> 2017 May  3 21:50:29+00:00 wglng-6 charon [info] 13[NET] received 
>> packet: from 76.232.248.210[4500] to 166.204.98.165[4500] (96 bytes)
>> 2017 May  3 21:50:29+00:00 wglng-6 charon [info] 13[ENC] parsed 
>> INFORMATIONAL response 23 [ ]
>> 2017 May  3 21:50:31+00:00 wglng-6 charon [info] 15[IKE] retransmit 1 
>> of request with message ID 95
>> 2017 May  3 21:50:31+00:00 wglng-6 charon [info] 15[NET] sending 
>> packet: from 192.168.1.134[500] to 76.232.248.210[500] (96 bytes)
>> 2017 May  3 21:50:31+00:00 wglng-6 charon [info] 04[NET] error writing 
>> to socket: Invalid argument
>>
>> It can't send any packets though, because the address 192.168.1.134 isn't bound to any active interface.
>>
>> That ends with this:
>>
>> 2017 May  3 21:50:50+00:00 wglng-6 charon [info] 07[ENC] parsed 
>> INFORMATIONAL response 33 [ ]
>> 2017 May  3 21:50:51+00:00 wglng-6 charon [info] 12[IKE] giving up 
>> after 5 retransmits
>> 2017 May  3 21:50:51+00:00 wglng-6 charon [info] 12[IKE] looking up 
>> interface for virtual IP 20.20.20.6 failed
>> 2017 May  3 21:50:51+00:00 wglng-6 charon [info] 12[IKE] restarting 
>> CHILD_SA sgateway1-gldl
>> 2017 May  3 21:50:51+00:00 wglng-6 charon [info] 12[IKE] initiating 
>> IKE_SA sgateway1-gldl[3] to 76.232.248.210
>> 2017 May  3 21:50:51+00:00 wglng-6 charon [info] 12[IKE] initiating 
>> IKE_SA sgateway1-gldl[3] to 76.232.248.210
>> 2017 May  3 21:50:51+00:00 wglng-6 charon [info] 13[IKE] sending DPD 
>> request
>>
>> This continues until the end of the log. The interface eth1.13 doesn't come up in the logs after it was deactivated.
>>
>> The PCAPs are pretty useless, because they don't show the problem. But ESP traffic indeed flows through the different network interfaces.
>> Hmh. Curious! I wonder why that is.
>>
>> On 04.05.2017 01:25, Modster, Anthony wrote:
>>> Hello Noel
>>>
>>> I am resending the message and for files are compressed.
>>>
>>> -----Original Message-----
>>> From: Modster, Anthony
>>> Sent: Wednesday, May 03, 2017 2:55 PM
>>> To: 'Noel Kuntze' 
>>> <noel.kuntze+strongswan-users-ml at thermi.consulting>;
>>> users at lists.strongswan.org
>>> Subject: RE: [SUSPECT EMAIL: No Reputation] Re: [strongSwan] [SUSPECT
>>> EMAIL: No Reputation] Re: [SUSPECT EMAIL: No Reputation] multiple 
>>> tunnels
>>>
>>> Hello Noel
>>>
>>> 1. let me know if any of the files are missing (s/b 3) 2. let me know 
>>> if the log levels are ok (our settings were more than support
>>> required)
>>>
>>> The following test and its results will be sent to strongswan for eveluation.
>>>
>>> bring up ethernet eth1.13
>>> when interface comes up start, tcpdump -i eth1.13 -w 
>>> test_restart_eth113.dat
>>> note: ipsec tunnel will start
>>> wait for tunnel
>>> bring up ppp0
>>> when interface comes up start, tcpdump -i ppp0 -w 
>>> test_restart_ppp0.dat wait for tunnel disconnect ethernet
>>> note: ppp0 will stop communicating
>>> wait for ppp0 to recover (about 9 mins)
>>>
>>> log files:
>>> test_restart_eth113.dat
>>> test_restart_ppp0.dat
>>> test_restart_security_edit.log
>>>
>>>
>>> -----Original Message-----
>>> From: Noel Kuntze
>>> [mailto:noel.kuntze+strongswan-users-ml at thermi.consulting]
>>> Sent: Wednesday, May 03, 2017 1:37 PM
>>> To: Modster, Anthony <Anthony.Modster at Teledyne.com>; 
>>> users at lists.strongswan.org
>>> Subject: [SUSPECT EMAIL: No Reputation] Re: [strongSwan] [SUSPECT
>>> EMAIL: No Reputation] Re: [SUSPECT EMAIL: No Reputation] multiple 
>>> tunnels
>>>
>>> For each interface.
>>>
>>> On 03.05.2017 22:24, Modster, Anthony wrote:
>>>> Hello Noel
>>>>
>>>> Quick question, do you want the tcpdump capture for each interface, or capture at the secure gateway side.
>>>>
>>>> -----Original Message-----
>>>> From: Noel Kuntze
>>>> [mailto:noel.kuntze+strongswan-users-ml at thermi.consulting]
>>>> Sent: Wednesday, May 03, 2017 12:08 PM
>>>> To: Modster, Anthony <Anthony.Modster at Teledyne.com>; 
>>>> users at lists.strongswan.org
>>>> Subject: [SUSPECT EMAIL: No Reputation] Re: [SUSPECT EMAIL: No 
>>>> Reputation] multiple tunnels
>>>>
>>>> Hello Anthony,
>>>>
>>>> On 03.05.2017 20:36, Modster, Anthony wrote:
>>>>> Each tunnel would be bound to a separate interface (eth1.13 and ppp0).
>>>>> Our application would open a socket for each tunnel end point, and bind to it (so there is no routing needed).
>>>> What kind of socket? Raw IP?
>>>>
>>>>> We verified that ESP packets are being sent from each application socket to the assigned interface.
>>>> Huh? Don't you mean "We verified that ESP packets are sent for each packet that is emitted from the application socket to the assigned interface"?
>>>>
>>>>> We verified that IKE packets are being sent to each interface from Charon.
>>>> This is very curious. Please verify that they are indeed sent out from two different interfaces.
>>>> As I previously mentioned, routing decisions are made based on the destination address, not the source address, so IKE packets for either IKE_SA would traverse the same interface and use the same route, except if you used policy based routing.
>>>>
>>>> Anyway, I require logs to figure out what happens exactly. Please create them using the file logger definition from the HelpRequests[1] page.
>>>>
>>>> Kind regards,
>>>> Noel
>>>>
>>>> [1]
>>>> https://secure-web.cisco.com/1j3GkDWiMC47CUy7JEZrTMFVOcm1wcAG1qjUD4e
>>>> j
>>>> w
>>>> TAGcl7Ie8pH_oYW3ermSmwJCHgfvbtGVlYFEBP8roXNFVxQH5MyW5aLMsU9pDAUSxyzC
>>>> A
>>>> s
>>>> lioVIyuREQoLk_-CP9Gus-3GQRkuDUOYzov0N5ZPq6tsv_2mW9NGMkRK-O3WZpWyeuW-
>>>> W
>>>> H
>>>> B5bGM1JBQu1w0xtwPy7ehB2hEZcy-cCyXQ/https%3A%2F%2Fwiki.strongswan.org
>>>> %
>>>> 2 Fprojects%2Fstrongswan%2Fwiki%2FHelpRequests
>>>>
>>>>> ? does this sound ok
>>>>> I will send more after your response.
>>>>>
>>>>> -----Original Message-----
>>>>> From: Noel Kuntze
>>>>> [mailto:noel.kuntze+strongswan-users-ml at thermi.consulting]
>>>>> Sent: Wednesday, May 03, 2017 10:38 AM
>>>>> To: Modster, Anthony <Anthony.Modster at Teledyne.com>; 
>>>>> users at lists.strongswan.org
>>>>> Subject: [SUSPECT EMAIL: No Reputation] Re: [strongSwan] [SUSPECT
>>>>> EMAIL: No Reputation] Re: multiple tunnels
>>>>>
>>>>> Hello Anthony,
>>>>>
>>>>> On 03.05.2017 19:24, Modster, Anthony wrote:
>>>>>> We are using two interfaces at once from same host to the same secure gateway.
>>>>> Why?
>>>>> Why even two IKE_SAs? Just use one IKE_SA and have the two CHILD_SAs be managed under one.
>>>>>
>>>>>> root at wglng-6:~# ip route show
>>>>>> 10.64.64.64 dev ppp0  proto kernel  scope link  src 166.204.4.61
>>>>>> 192.168.1.0/24 dev eth1.13  proto kernel  scope link  src
>>>>>> 192.168.1.134
>>>>>> Note: I did not show interfaces that are not applicable
>>>>>>
>>>>>> Both tunnels are up and were able to ping and send data thru the tunnels.
>>>>>> root at wglng-6:~# swanctl --list-sas
>>>>>> sgateway1-radio0: #2, ESTABLISHED, IKEv2, 08173d8797a410eb_i* 5fa1f29dce075fd4_r
>>>>>>   local  'RA00006 at Teledyne.com' @ 166.204.4.61[4500] [20.20.20.9]
>>>>>>   remote 'C=CA, O=Carillon Information Security Inc., OU=TEST, OU=Devices, OU=Aircraft Operator Ground Stations, OU=Teledyne Controls, CN=ELS-VPAPP-WGL08 - ID' @ 76.232.248.210[4500]
>>>>>>   AES_CBC-256/HMAC_SHA2_512_256/PRF_HMAC_SHA1/ECP_256
>>>>>>   established 922s ago, rekeying in 43s, reauth in 2455s
>>>>>>   sgateway1-radio0: #4, reqid 2, INSTALLED, TUNNEL-in-UDP, ESP:AES_CBC-256/HMAC_SHA1_96
>>>>>>     installed 336s ago, rekeying in 211s, expires in 325s
>>>>>>     in  c2e01069,   1320 bytes,    33 packets,     6s ago
>>>>>>     out e1c27d5f,   1452 bytes,    33 packets,     6s ago
>>>>>>     local  20.20.20.9/32
>>>>>>     remote 10.100.20.15/32
>>>>>> sgateway1-gldl: #1, ESTABLISHED, IKEv2, 00989cc440834937_i* 5e3c5e4b5c1ec4cf_r
>>>>>>   local  'RA00006 at Teledyne.com' @ 192.168.1.134[4500] [20.20.20.8]
>>>>>>   remote 'C=CA, O=Carillon Information Security Inc., OU=TEST, OU=Devices, OU=Aircraft Operator Ground Stations, OU=Teledyne Controls, CN=ELS-VPAPP-WGL08 - ID' @ 76.232.248.210[4500]
>>>>>>   AES_CBC-256/HMAC_SHA2_512_256/PRF_HMAC_SHA1/ECP_256
>>>>>>   established 1049s ago, rekeying in 150s, reauth in 2257s
>>>>>>   sgateway1-gldl: #3, reqid 1, INSTALLED, TUNNEL-in-UDP, ESP:AES_CBC-256/HMAC_SHA1_96
>>>>>>     installed 469s ago, rekeying in 104s, expires in 191s
>>>>>>     in  c45db512,   1880 bytes,    47 packets,     6s ago
>>>>>>     out 77309eef,   2068 bytes,    47 packets,     6s ago
>>>>>>     local  20.20.20.8/32
>>>>>>     remote 10.100.20.15/32
>>>>>>
>>>>>> strongswan creates the following in table 220 root at wglng-6:~# ip 
>>>>>> route show table 220
>>>>>> 10.100.20.15 via 192.168.1.1 dev eth1.13  proto static  src
>>>>>> 20.20.20.8
>>>>>>
>>>>>> When we bring down eth1.13, the tunnel for ppp0 becomes unusable.
>>>>> What do you mean with "the tunnel for ppp0"? The interface is irrelevant.
>>>>> Packets are routed based on their destination. Charon does not pick two different paths for two different IKE_SAs to the same peer.
>>>>>
>>>>> Are you aware that charon uses one path for all the IKE_SAs to one peer?
>>>>> Charon should choose another path to the remote peer, if there is one (and the "src" parameter of the corresponding route allows that). I guess your routing table doesn't allow that.
>>>>>
>>>>> Please provide logs that show the problem.
>>>>>
>>>>>> We think the problem is that ppp0 does not have a via in table 220.
>>>>> Irrelevant. See above.
>>>>>
>>>>>> If you need more information, let me know.
>>>>>>
>>>>>> Thanks
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Noel Kuntze
>>>>>> [mailto:noel.kuntze+strongswan-users-ml at thermi.consulting]
>>>>>> Sent: Wednesday, May 03, 2017 7:33 AM
>>>>>> To: Modster, Anthony <Anthony.Modster at Teledyne.com>; 
>>>>>> users at lists.strongswan.org
>>>>>> Subject: [SUSPECT EMAIL: No Reputation] Re: [strongSwan] multiple 
>>>>>> tunnels
>>>>>>
>>>>>> Hello Anthony,
>>>>>>
>>>>>> On 03.05.2017 06:57, Modster, Anthony wrote:
>>>>>>>  
>>>>>>>
>>>>>>> ? how to setup ipsec policy
>>>>>>>
>>>>>>>  
>>>>>>>
>>>>>>> We want to use multiple tunnels on separate interfaces on the same host to one secure gateway.
>>>>>>>
>>>>>>>  
>>>>>>>
>>>>>>> The secure gateway only has one external IP address.
>>>>>>>
>>>>>> Depends on your exact requirements. You need to elaborate on this.
>>>>>>
>>>>>> Kind regards,
>>>>>> Noel
>>>>>>
>>>>>> -- Noel Kuntze IT security consultant GPG Key ID: 0x0739AD6C
>>>>>> Fingerprint: 3524 93BE B5F7 8E63 1372 AF2D F54E E40B 0739 AD6C 
>>>>>> _______________________________________________ Users mailing list 
>>>>>> Users at lists.strongswan.org 
>>>>>> https://secure-web.cisco.com/1umLFBujqnWj6QpzkmjOs5N9U3Ek-8bie0MXp
>>>>>> B
>>>>>> 6
>>>>>> w
>>>>>> Z
>>>>>> 9ss1vhilBrSfF13tKoWL6NTRe0CPd1SRvuy2CT2LgFRD1gjLQ21atsRzKU836Zbhig
>>>>>> A
>>>>>> z
>>>>>> 4
>>>>>> k
>>>>>> 14W-T9yeoOC4t2-xDiwbecTeWHYlRtlO1w7TQmXEEzPLgNH25aPblOjUYxnVk3llkY
>>>>>> q
>>>>>> 0
>>>>>> W
>>>>>> l
>>>>>> d7pEH7cKab9tMboT6476CmpbjuM8HztzzA/https%3A%2F%2Flists.strongswan.
>>>>>> o
>>>>>> r
>>>>>> g
>>>>>> %
>>>>>> 2Fmailman%2Flistinfo%2Fusers
>>>>>>
>>>> _______________________________________________
>>>> Users mailing list
>>>> Users at lists.strongswan.org
>>>> https://secure-web.cisco.com/1ZUqhowo0_mv9V5kD25oaNH8gLBZLx66slK6Ff2
>>>> 1
>>>> L
>>>> c9NCBKfl3Gs-GcDc9rITZdgrJ-gm4T7JliTiQ8tSyQ00Yvr4q_dP85oAHK-y6amf1lwg
>>>> W
>>>> 4
>>>> AgyJ5jvH2M04bEqEFcCxg6lss3F2tKV0s2k6RGOVF2-XjR0apCbvx4RxQkwAj2uGqSXz
>>>> j
>>>> f
>>>> ZJzz0AqTsW6cseBSHwc-jMy4lczBfcy-Zg/https%3A%2F%2Flists.strongswan.or
>>>> g
>>>> %
>>>> 2Fmailman%2Flistinfo%2Fusers
>>>>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.strongswan.org/pipermail/users/attachments/20170504/612bb300/attachment-0001.sig>

More information about the Users mailing list