On 04.05.2017 17:27, Modster, Anthony wrote: > Hello Noel > > If I disable route installation. > > ? can a custom _updown script be used to set the route for each tunnel
Phew. I think you can, but you have to take care not to install duplicate routes. The hook you need to put your commands into, is called with each combination of subnets. > > ? or can the "event monitor" callback be used to set the route for each tunnel Yes, if you use VICI. You can script something with Python using the vici egg. > > -----Original Message----- > From: Noel Kuntze [mailto:[email protected]] > Sent: Thursday, May 04, 2017 8:22 AM > To: Modster, Anthony <[email protected]>; > [email protected] > Subject: [SUSPECT EMAIL: No Reputation] Re: [SUSPECT EMAIL: No Reputation] > Re: [SUSPECT EMAIL: No Reputation] multiple tunnels > > 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:[email protected]] >> Sent: Thursday, May 04, 2017 4:12 AM >> To: Modster, Anthony <[email protected]>; >> [email protected] >> 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:[email protected]] >>> Sent: Wednesday, May 03, 2017 4:45 PM >>> To: Modster, Anthony <[email protected]>; >>> [email protected] >>> 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' >>>> <[email protected]>; >>>> [email protected] >>>> 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:[email protected]] >>>> Sent: Wednesday, May 03, 2017 1:37 PM >>>> To: Modster, Anthony <[email protected]>; >>>> [email protected] >>>> 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:[email protected]] >>>>> Sent: Wednesday, May 03, 2017 12:08 PM >>>>> To: Modster, Anthony <[email protected]>; >>>>> [email protected] >>>>> 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/1j3GkDWiMC47CUy7JEZrTMFVOcm1wcAG1qjUD4 >>>>> e >>>>> j >>>>> w >>>>> TAGcl7Ie8pH_oYW3ermSmwJCHgfvbtGVlYFEBP8roXNFVxQH5MyW5aLMsU9pDAUSxyz >>>>> C >>>>> A >>>>> s >>>>> lioVIyuREQoLk_-CP9Gus-3GQRkuDUOYzov0N5ZPq6tsv_2mW9NGMkRK-O3WZpWyeuW >>>>> - >>>>> W >>>>> H >>>>> B5bGM1JBQu1w0xtwPy7ehB2hEZcy-cCyXQ/https%3A%2F%2Fwiki.strongswan.or >>>>> g >>>>> % >>>>> 2 Fprojects%2Fstrongswan%2Fwiki%2FHelpRequests >>>>> >>>>>> ? does this sound ok >>>>>> I will send more after your response. >>>>>> >>>>>> -----Original Message----- >>>>>> From: Noel Kuntze >>>>>> [mailto:[email protected]] >>>>>> Sent: Wednesday, May 03, 2017 10:38 AM >>>>>> To: Modster, Anthony <[email protected]>; >>>>>> [email protected] >>>>>> 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@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@wglng-6:~# swanctl --list-sas >>>>>>> sgateway1-radio0: #2, ESTABLISHED, IKEv2, 08173d8797a410eb_i* >>>>>>> 5fa1f29dce075fd4_r >>>>>>> local '[email protected]' @ 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 '[email protected]' @ 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@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:[email protected]] >>>>>>> Sent: Wednesday, May 03, 2017 7:33 AM >>>>>>> To: Modster, Anthony <[email protected]>; >>>>>>> [email protected] >>>>>>> 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 [email protected] >>>>>>> https://secure-web.cisco.com/1umLFBujqnWj6QpzkmjOs5N9U3Ek-8bie0MX >>>>>>> p >>>>>>> B >>>>>>> 6 >>>>>>> w >>>>>>> Z >>>>>>> 9ss1vhilBrSfF13tKoWL6NTRe0CPd1SRvuy2CT2LgFRD1gjLQ21atsRzKU836Zbhi >>>>>>> g >>>>>>> A >>>>>>> z >>>>>>> 4 >>>>>>> k >>>>>>> 14W-T9yeoOC4t2-xDiwbecTeWHYlRtlO1w7TQmXEEzPLgNH25aPblOjUYxnVk3llk >>>>>>> Y >>>>>>> q >>>>>>> 0 >>>>>>> W >>>>>>> l >>>>>>> d7pEH7cKab9tMboT6476CmpbjuM8HztzzA/https%3A%2F%2Flists.strongswan. >>>>>>> o >>>>>>> r >>>>>>> g >>>>>>> % >>>>>>> 2Fmailman%2Flistinfo%2Fusers >>>>>>> >>>>> _______________________________________________ >>>>> Users mailing list >>>>> [email protected] >>>>> https://secure-web.cisco.com/1ZUqhowo0_mv9V5kD25oaNH8gLBZLx66slK6Ff >>>>> 2 >>>>> 1 >>>>> L >>>>> c9NCBKfl3Gs-GcDc9rITZdgrJ-gm4T7JliTiQ8tSyQ00Yvr4q_dP85oAHK-y6amf1lw >>>>> g >>>>> W >>>>> 4 >>>>> AgyJ5jvH2M04bEqEFcCxg6lss3F2tKV0s2k6RGOVF2-XjR0apCbvx4RxQkwAj2uGqSX >>>>> z >>>>> j >>>>> f >>>>> ZJzz0AqTsW6cseBSHwc-jMy4lczBfcy-Zg/https%3A%2F%2Flists.strongswan.o >>>>> r >>>>> g >>>>> % >>>>> 2Fmailman%2Flistinfo%2Fusers >>>>>
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Users mailing list [email protected] https://lists.strongswan.org/mailman/listinfo/users
