Re: [strongSwan] What adds the rule for route table 220?

Hi Ben, In charon.conf, the routing_table option lets you configure the table number. The comment associated with this option does not say what is the accepted range, though.     Hoggins! Le 18/09/2019 à 19:12, Ben Greear a écrit : > On 9/18/19 9:58 AM, Tobias Brunner wrote: >&g

Re: [strongSwan] Source IP in routing table

-101 And my rules: 0:    from all lookup local 220:    from all lookup 220 32766:    from all lookup main 32767:    from all lookup default     Hoggins! Le 28/12/2018 à 15:01, Noel Kuntze a écrit : > Hello, > > strongSwan generally uses the routing table(s) for figuring

Re: [strongSwan] Source IP in routing table

Well, I got away with setting install_routes to no and manually installing them on startup. I guess I could use a leftupdown script to get all this when the tunnel is closed/reopened. Anyway that'd be nice to have some control over these routes when install_routes is set to yes.     Hoggins

[strongSwan] Source IP in routing table

as the source one. Any idea? Thanks!     Hoggins! signature.asc Description: OpenPGP digital signature

Re: [strongSwan] Upgrade client to 5.6.3, get AUTH_FAILED

e /usr/local/ prefix, so both of them will look for the same ipsec.conf and ipsec.secrets config files. Little lost here. Le 14/07/2018 à 11:39, Hoggins! a écrit : > Hello, > > I bumped into a strange problem and I was wondering if you could help me : > > Sun is my StrongSWAN &q

[strongSwan] Upgrade client to 5.6.3, get AUTH_FAILED

have changed on both peers, and are both readable and listed, but the newly upgraded Moon cannot authenticate properly and gets rejected. Any idea?     Thank you!         Hoggins! signature.asc Description: OpenPGP digital signature

Re: [strongSwan] "signal of type SIGINT received. Shutting down" ?

Here is what I used, and it's correctly matching : iptables -A OUTPUT -p udp -m udp --dport 4500 -m u32 --u32 "28&0x=0x0" -j MARK Thanks again ! Le 25/01/2018 à 19:22, Simon Deziel a écrit : > On 2018-01-25 12:35 PM, Hoggins! wrote: >> I'm just trying to make sur

Re: [strongSwan] "signal of type SIGINT received. Shutting down" ?

Le 25/01/2018 à 19:22, Simon Deziel a écrit : Maybe you can configure IPtables to look for those 4 bytes of 0s [1] when the UDP/4500 packet is an IKE one? [1] https://docs.microsoft.com/en-us/windows-hardware/drivers/network/udp-esp-encapsulation-types

Re: [strongSwan] "signal of type SIGINT received. Shutting down" ?

Le 25/01/2018 à 19:25, Jafar Al-Gharaibeh a écrit : > > On 1/25/2018 11:35 AM, Hoggins! wrote: >> I'm just trying to make sure that I'm able to fine select different >> types of traffic on outbound UDP 4500 (we use NAT-T), and right now it >> seems that I'm still also

Re: [strongSwan] "signal of type SIGINT received. Shutting down" ?

Thank you ! It's important to know if we're heading towards the right direction. Le 25/01/2018 à 17:51, Jafar Al-Gharaibeh a écrit : > We have the same situation, traffic shaping/capping.  Whether  it is > an IKE packet > any other control packet, it is up to you (traffic shaping) to decide >

[strongSwan] Marking DPD / signalling traffic [WAS : "signal of type SIGINT received. Shutting down" ?]

My previous attempts to match only DSCP 0x2e don't seem to be the best solution. Could I simply tell StrongSwan to place an iptables xmark on its DPD / signalling outbound packets ?     Hoggins! Le 25/01/2018 à 16:28, Hoggins! a écrit : > Following the little diary of my experiments, h

Re: [strongSwan] "signal of type SIGINT received. Shutting down" ?

, matching with an iptables rule to push the DSCP 0x2e packets through a priority lane. But am I doing it right ? Is there a better way ? What could I match to be sure that all the signalling packets have a higher priority than the data packets ? Thanks !     Hoggins! Le 20/01/2018 à 18:24, Hoggins

Re: [strongSwan] "signal of type SIGINT received. Shutting down" ?

after having failed, the tunnel is not reestablished, why the traps are not catching anything     Hoggins! Le 18/01/2018 à 14:38, Hoggins! a écrit : > Thank you Anvar, > > Le 18/01/2018 à 14:09, Anvar Kuchkartaev a écrit : >> I had similar type of error and it was kernel-libipsec plug

Re: [strongSwan] "signal of type SIGINT received. Shutting down" ?

bipsec and no TUN device is created on the host, so I believe the plugin is already inactive on my implementation. I guess the Truth is out there.     Hoggins! signature.asc Description: OpenPGP digital signature

[strongSwan] "signal of type SIGINT received. Shutting down" ?

lose packets. Where should I look ? Thanks !     Hoggins! signature.asc Description: OpenPGP digital signature

Re: [strongSwan] Lots of reconnections for a rekey/reauth, and packet drops

Actually, I might be ending here : https://wiki.strongswan.org/issues/2446 It looks really familiar. Le 05/12/2017 à 16:26, Hoggins! a écrit : > Hello Tobias, > > Le 05/12/2017 à 15:54, Tobias Brunner a écrit : >> Using auto=start on both ends in combination with uniqueids=yes and

Re: [strongSwan] Lots of reconnections for a rekey/reauth, and packet drops

Thank you Rajiv, Unfortunately, this changed nothing. Now I have mobike=no on both sides, and I still experience the same reconnection issues. Le 05/12/2017 à 06:55, Rajiv Kulkarni a écrit : > mobike=no is missing in node2...i think thats whats causing the > rekeys/deletes...i may be wrong...but

Re: [strongSwan] Lots of reconnections for a rekey/reauth, and packet drops

3.4[4500] to 4.3.2.1[34534] (272 bytes) Can you see something ?     Thanks !         Hoggins! Le 01/12/2017 à 10:50, Hoggins! a écrit : > Hello Tobias, > > Le 30/11/2017 à 18:16, Tobias Brunner a écrit : >> Hi, >> >> Combining reauthentication with closeaction=rest

Re: [strongSwan] Lots of reconnections for a rekey/reauth, and packet drops

Hello Tobias, Le 30/11/2017 à 18:16, Tobias Brunner a écrit : > Hi, > > Combining reauthentication with closeaction=restart is a bad idea. Note > that reauth=no does not disable reauthentication if the other peer has > reauth=yes configured, see [1]. Yes, I removed the reauth=no option. It had

Re: [strongSwan] Lots of reconnections for a rekey/reauth, and packet drops

Hello Noel, Thanks for these insights ! Le 28/11/2017 à 23:30, Noel Kuntze a écrit : > Hi, > >> Nov 28 16:52:29 yomama charon: 06[KNL] creating delete job for >> CHILD_SA ESP/0xc4bd0735/192.168.1.72 >> Nov 28 16:52:29 yomama charon: 06[JOB] CHILD_SA >> ESP/0xc4bd0735/192.168.1.72

[strongSwan] Lots of reconnections for a rekey/reauth, and packet drops

n some absurd values, will be greatly appreciated ! Thanks !     Hoggins! signature.asc Description: OpenPGP digital signature

Re: [strongSwan] High latency (satellite) link : what can we improve ?

  left=51.254.26.13   leftsubnet=192.168.55.0/24,192.168.33.0/24,192.168.66.0/24   leftfirewall=yes   right=%any   rightsubnet=192.168.22.0/24   rightid=netnetYomama   auto=start I'll do my best to extract some logs. Thanks ! Le 26/10/2017 à 19:19, Noel Kuntze a écri

Re: [strongSwan] High latency (satellite) link : what can we improve ?

[...] Connection is *not* automatically established when needed [...] Le 26/10/2017 à 10:31, Hoggins! a écrit : > With this in place, strongswan statusall shows that there are policies > loaded, but connection is automatically established when needed, > although I thought this would be

Re: [strongSwan] High latency (satellite) link : what can we improve ?

help ? Or do we need to manually start the connection ?     Hoggins! Le 25/10/2017 à 13:38, Hoggins! a écrit : > Thank you Tom, > > Seeing your first answer, I also had this kind of memory, but I was > unable to find it as well. > I'll set this and try it out ! > >     Hoggi

Re: [strongSwan] High latency (satellite) link : what can we improve ?

Thank you Tom, Seeing your first answer, I also had this kind of memory, but I was unable to find it as well. I'll set this and try it out !     Hoggins! Le 25/10/2017 à 12:43, Tom Rymes a écrit : > I would recommend that you try auto=route. My experience suggests that it > signifi

Re: [strongSwan] High latency (satellite) link : what can we improve ?

Le 24/10/2017 à 18:52, Tom Rymes a écrit : > On Oct 24, 2017, at 11:53 AM, Hoggins! <hogg...@radiom.fr> wrote: >> Hello, >> >> We sometimes use a satellite link for one of our site2sites tunnels, and >> there are times when the tunnel simply stops worki

[strongSwan] High latency (satellite) link : what can we improve ?

and ensure a connection without dropouts ? Thank you !     Hoggins! signature.asc Description: OpenPGP digital signature

[strongSwan] Tunnels "slowing"

ing for me is that I just need to restart the "server" service to get things back at normal operation. Thanks !     Hoggins! signature.asc Description: OpenPGP digital signature

[strongSwan] Retries after authentication failure

, and without asking for a feature inside Strongswan, I was wondering if you guys had had similar needs and had figured out how to trigger a retry anyway on client side. Thanks ! Hoggins! signature.asc Description: OpenPGP digital signature

[strongSwan] Basic failover question

we'll see what we can do" ? ... or something like that ? Thanks ! Hoggins! signature.asc Description: OpenPGP digital signature ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users

Re: [strongSwan] Road warriors and site-to-site ping each other

Thank you ! I'm currently using a solution from a third-party provider, and there are not many things I can configure on gateway B (like adding CHILD_SAs, for example). I'll go with my own implementation of Strongswan for a better control over the configuration. Thanks ! Hoggins! Le 13/03

[strongSwan] Road warriors and site-to-site ping each other

the exact configuration of gateway B, it is provided "as is" by a third-party, and might not even be a StrongSwan implementation. Thank you for your help. Hoggins! signature.asc Description: OpenPGP digital signature ___ Users mailing

Re: [strongSwan] Source routing with StrongSwan

Agreed. Le 14/12/2016 à 21:33, Noel Kuntze a écrit : >> Alas, I'm afraid that by "iptables", you are referring to the remote >> > Strongswan peer, on the same network as my desired final gateway. I have >> > no control over this machine, and I cannot set any iptables rule on this >> > one. > No,

Re: [strongSwan] Source routing with StrongSwan

Thank you Noel Le 12/12/2016 à 16:24, Noel Kuntze a écrit : > Hello Hoggins, > > On 12.12.2016 14:47, Hoggins! wrote: >> > How could I achieve this ? > Not like how you tried. > You either need to build a route based IPsec tunnel and then do policy based > routing

[strongSwan] Source routing with StrongSwan

192.168.22.0/24 table 100 But of course, when I do this : ip route add default via 192.168.55.3 table 100 ...it answers that host 192.168.55.3 is unreachable. I guess it's because it's a non-local host, not present in the local routing table. How could I achieve this ? Thanks ! Hoggins

Re: [strongSwan] Cannot ping in tunnel

ze a écrit : > Hello Hoggins, > > Fix your iptables rules. Look at all the tables. Traffic flows through the > different tables and chains. There's no special handling of IPsec packets. > signature.asc Description: OpenPGP digital signature

Re: [strongSwan] Cannot ping in tunnel

Just compiled and installed Strongswan 5.5.1 ("Linux strongSwan U5.5.1/K4.4.8"), still no luck. Le 07/12/2016 à 11:45, Hoggins! a écrit : > Hello list, > > This is my first post here, I'm hoping I'm not asking something too stupid. > > I have a tunnel definition toward

[strongSwan] Cannot ping in tunnel

55.0/24 But I can't ping any address in 192.168.55.0/24. Can you help me on what additional info I need to provide to help debugging ? Thanks ! Hoggins! signature.asc Description: OpenPGP digital signature ___ Users mailing list Us