[strongSwan] [SUSPECT EMAIL: No Reputation] multiple tunnels
Noel Kuntze
noel.kuntze+strongswan-users-ml at thermi.consulting
Wed May 3 21:07:39 CEST 2017
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://wiki.strongswan.org/projects/strongswan/wiki/HelpRequests
>
> ? 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-8bie0MXpB6wZ
>> 9ss1vhilBrSfF13tKoWL6NTRe0CPd1SRvuy2CT2LgFRD1gjLQ21atsRzKU836ZbhigAz4k
>> 14W-T9yeoOC4t2-xDiwbecTeWHYlRtlO1w7TQmXEEzPLgNH25aPblOjUYxnVk3llkYq0Wl
>> d7pEH7cKab9tMboT6476CmpbjuM8HztzzA/https%3A%2F%2Flists.strongswan.org%
>> 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/20170503/cf05a4ed/attachment-0001.sig>
More information about the Users
mailing list