[strongSwan] [SUSPECT EMAIL: No Reputation] Re: [SUSPECT EMAIL: No Reputation] Re: [SUSPECT EMAIL: No Reputation] multiple tunnels
Noel Kuntze
noel.kuntze+strongswan-users-ml at thermi.consulting
Wed May 3 23:14:56 CEST 2017
I did. Some software on your end converted it into some obscure "https://secure-web.cisco.com" link.
On 03.05.2017 23:00, Modster, Anthony wrote:
> Hello Noel
>
> ? can you send me the link to "HelpRequests[1] page"
>
> -----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/1j3GkDWiMC47CUy7JEZrTMFVOcm1wcAG1qjUD4ejw
>> TAGcl7Ie8pH_oYW3ermSmwJCHgfvbtGVlYFEBP8roXNFVxQH5MyW5aLMsU9pDAUSxyzCAs
>> lioVIyuREQoLk_-CP9Gus-3GQRkuDUOYzov0N5ZPq6tsv_2mW9NGMkRK-O3WZpWyeuW-WH
>> 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-8bie0MXpB6
>>>> w
>>>> Z
>>>> 9ss1vhilBrSfF13tKoWL6NTRe0CPd1SRvuy2CT2LgFRD1gjLQ21atsRzKU836ZbhigAz
>>>> 4
>>>> k
>>>> 14W-T9yeoOC4t2-xDiwbecTeWHYlRtlO1w7TQmXEEzPLgNH25aPblOjUYxnVk3llkYq0
>>>> W
>>>> l
>>>> d7pEH7cKab9tMboT6476CmpbjuM8HztzzA/https%3A%2F%2Flists.strongswan.or
>>>> g
>>>> %
>>>> 2Fmailman%2Flistinfo%2Fusers
>>>>
>> _______________________________________________
>> Users mailing list
>> Users at lists.strongswan.org
>> https://secure-web.cisco.com/1ZUqhowo0_mv9V5kD25oaNH8gLBZLx66slK6Ff21L
>> c9NCBKfl3Gs-GcDc9rITZdgrJ-gm4T7JliTiQ8tSyQ00Yvr4q_dP85oAHK-y6amf1lwgW4
>> AgyJ5jvH2M04bEqEFcCxg6lss3F2tKV0s2k6RGOVF2-XjR0apCbvx4RxQkwAj2uGqSXzjf
>> ZJzz0AqTsW6cseBSHwc-jMy4lczBfcy-Zg/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/b3d3da97/attachment.sig>
More information about the Users
mailing list