Re: [strongSwan] mobike

[Martin Willi]

Hi,

> Apr  6 08:36:57 csp-laptop charon: 17[IKE] requesting address change using
> MOBIKE
> Apr  6 08:36:57 csp-laptop charon: 17[ENC] generating INFORMATIONAL request
> 2 [ ]
> Apr  6 08:36:57 csp-laptop charon: 17[IKE] checking path 192.168.5.80[4500]
> - 194.116.5.51[4500]
> Apr  6 08:36:57 csp-laptop charon: 17[NET] sending packet: from
> 192.168.5.80[4500] to 194.116.5.51[4500]
> Apr  6 08:36:57 csp-laptop charon: 06[NET] error writing to socket: Invalid
> argument
...
> Apr  6 08:37:22 csp-laptop charon: 17[IKE] path probing attempt 10
> Apr  6 08:37:22 csp-laptop charon: 17[IKE] checking path 192.168.5.80[4500]
> - 194.116.5.51[4500]
> Apr  6 08:37:22 csp-laptop charon: 17[NET] sending packet: from
> 192.168.5.80[4500] to 194.116.5.51[4500]
> Apr  6 08:37:22 csp-laptop charon: 06[NET] error writing to socket: Invalid
> argument
> Apr  6 08:37:25 csp-laptop charon: 03[IKE] giving up after 10 path probings

Charon tries to find a valid path within 25 seconds or so, but closes
the IKE_SA if migrating the tunnel fails. It seems that this is not
enough for your reconnect to the second AP. 
You may try to change the path probing behavior by changing [1] or [2].

This behavior is probably not optimal: we probably should use a routing
lookup to see if we can still reach the gateway and set the SA state to
something like STALE until we have a vaild route. But this is currently
not implemented.

Regards
Martin

[1]http://trac.strongswan.org/browser/trunk/src/charon/sa/task_manager.h#L53
[2]http://trac.strongswan.org/browser/trunk/src/charon/sa/task_manager.h#L58


___
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users

Re: [strongSwan] MOBIKE

[Tobias Brunner]

Hi Patricia,

 > it seems that some packets leave the tunnel during the handover
 > process.

I just checked in some changes to fix this problem [1].  These changes 
will be included in the upcoming 4.5.3 release.

The reason for the behavior you are observing is that charon, when it 
updates an IPsec SA, as caused by MOBIKE, first deletes and then readds 
the policies in the kernel.  Within the short timeframe during which no 
matching policy is installed in the kernel unencrypted packets could 
have been transmitted.  To avert this the existing policies are now 
replaced with DROP policies which in turn get replaced with the new 
policies.  The DROP policies effectively prevent any unencrypted packets 
from leaving (or entering) the host.

Regards,
Tobias

[1] http://git.strongswan.org/?p=strongswan.git;a=commitdiff;h=fbedc6a4
 http://git.strongswan.org/?p=strongswan.git;a=commitdiff;h=d7a59f19
 http://git.strongswan.org/?p=strongswan.git;a=commitdiff;h=f1c1965d

___
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users

Re: [strongSwan] MOBIKE

[Andreas Steffen]

Hello Patricia,

release candidate 2 is available which includes Tobias' patches:

  http://download.strongswan.org/strongswan-4.5.3rc2.tar.bz2

Regards

Andreas

On 07/28/2011 05:49 PM, Tobias Brunner wrote:
> Hi Patricia,
> 
>  > it seems that some packets leave the tunnel during the handover
>  > process.
> 
> I just checked in some changes to fix this problem [1].  These changes 
> will be included in the upcoming 4.5.3 release.
> 
> The reason for the behavior you are observing is that charon, when it 
> updates an IPsec SA, as caused by MOBIKE, first deletes and then readds 
> the policies in the kernel.  Within the short timeframe during which no 
> matching policy is installed in the kernel unencrypted packets could 
> have been transmitted.  To avert this the existing policies are now 
> replaced with DROP policies which in turn get replaced with the new 
> policies.  The DROP policies effectively prevent any unencrypted packets 
> from leaving (or entering) the host.
> 
> Regards,
> Tobias
> 
> [1] http://git.strongswan.org/?p=strongswan.git;a=commitdiff;h=fbedc6a4
>  http://git.strongswan.org/?p=strongswan.git;a=commitdiff;h=d7a59f19
>  http://git.strongswan.org/?p=strongswan.git;a=commitdiff;h=f1c1965d
> 

==
Andreas Steffen andreas.stef...@strongswan.org
strongSwan - the Linux VPN Solution!www.strongswan.org
Institute for Internet Technologies and Applications
University of Applied Sciences Rapperswil
CH-8640 Rapperswil (Switzerland)
===[ITA-HSR]==

___
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users

Re: [strongSwan] MOBIKE

[Tobias Brunner]

Hi Patricia,

 > I've tested strongswan-4.5.3rc2 and I still get the same behaviour.
 > I'm testing MOBIKE by sending CBR traffic from the initiator at a
 > rate of 45Kbps.
 >
> When I deactivate eth0 I obtain the behavior that you can see on one.png.
>
> Then, I activate eth0 again and deactivate eth1 and I obtain the
> behaviour showed in two.png (nothing strange).

Ah, the problem here is not exactly what I described previously and not 
quite what the patch fixes.  The problem in this situation is that the 
original IPsec SA covers packets between 163.117.141.82 and 
163.117.141.81.  Now, when 163.117.141.82 goes down, there is simply no 
IPsec SA yet which covers eth1's 163.117.14.33.  MOBIKE has first to 
determine this as a valid path and then update the SA appropriately. 
The submitted patch basically fixes this last update step.  So how do 
you fix it?  Well, you have to make sure that 'left' (the IP address 
that might change) is not part of the local traffic selector.  To do so 
I'd recommend you assign your client a virtual IP address.

Regards,
Tobias


___
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users

Re: [strongSwan] MOBIKE

[Patricia de Noriega]

hi Tobias,

On 29 July 2011 15:58, Tobias Brunner  wrote:

> Hi Patricia,
>
>
> > I've tested strongswan-4.5.3rc2 and I still get the same behaviour.
> > I'm testing MOBIKE by sending CBR traffic from the initiator at a
> > rate of 45Kbps.
> >
>
>> When I deactivate eth0 I obtain the behavior that you can see on one.png.
>>
>> Then, I activate eth0 again and deactivate eth1 and I obtain the
>> behaviour showed in two.png (nothing strange).
>>
>
> Ah, the problem here is not exactly what I described previously and not
> quite what the patch fixes.  The problem in this situation is that the
> original IPsec SA covers packets between 163.117.141.82 and 163.117.141.81.
>  Now, when 163.117.141.82 goes down, there is simply no IPsec SA yet which
> covers eth1's 163.117.14.33.  MOBIKE has first to determine this as a valid
> path and then update the SA appropriately. The submitted patch basically
> fixes this last update step.  So how do you fix it?  Well, you have to make
> sure that 'left' (the IP address that might change) is not part of the local
> traffic selector.  To do so I'd recommend you assign your client a virtual
> IP address.
>

I've test also with virtual IP's and I obtain the same behaviour :(

>
> Regards,
> Tobias
>
>
___
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users

Re: [strongSwan] MOBIKE

[Tobias Brunner]

Hi Patricia,

> I've test also with virtual IP's and I obtain the same behaviour :(

Ah, yes.  The source route installed by charon only covers eth0 and its 
default gateway.

Andreas, Martin, any ideas?

Regards,
Tobias

___
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users

Re: [strongSwan] MOBIKE

[Andreas Steffen]

Would it help to bind the virtual IP do a dummy interface, so that
when the physical interface goes away the source route still
exists and remains covered by the traffic selectors and thus by
the transient DROP policy for the TS.

Regards

Andreas

On 07/29/2011 04:12 PM, Tobias Brunner wrote:
> Hi Patricia,
> 
>> I've test also with virtual IP's and I obtain the same behaviour :(
> 
> Ah, yes.  The source route installed by charon only covers eth0 and its
> default gateway.
> 
> Andreas, Martin, any ideas?
> 
> Regards,
> Tobias

==
Andreas Steffen andreas.stef...@strongswan.org
strongSwan - the Linux VPN Solution!www.strongswan.org
Institute for Internet Technologies and Applications
University of Applied Sciences Rapperswil
CH-8640 Rapperswil (Switzerland)
===[ITA-HSR]==

___
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users

Re: [strongSwan] MOBIKE

[Patricia de Noriega]

How I can bind that interface by means of the ipsec.conf file?

Best regards,

On 29 July 2011 16:51, Andreas Steffen wrote:

> Would it help to bind the virtual IP do a dummy interface, so that
> when the physical interface goes away the source route still
> exists and remains covered by the traffic selectors and thus by
> the transient DROP policy for the TS.
>
> Regards
>
> Andreas
>
> On 07/29/2011 04:12 PM, Tobias Brunner wrote:
> > Hi Patricia,
> >
> >> I've test also with virtual IP's and I obtain the same behaviour :(
> >
> > Ah, yes.  The source route installed by charon only covers eth0 and its
> > default gateway.
> >
> > Andreas, Martin, any ideas?
> >
> > Regards,
> > Tobias
>
> ==
> Andreas Steffen andreas.stef...@strongswan.org
> strongSwan - the Linux VPN Solution!www.strongswan.org
> Institute for Internet Technologies and Applications
> University of Applied Sciences Rapperswil
> CH-8640 Rapperswil (Switzerland)
> ===[ITA-HSR]==
>
___
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users

Re: [strongSwan] MOBIKE

[Andreas Steffen]

Hello Patricia,

binding the virtual IP to a dummy interface currently isn't
supported by strongSwan. It was just a suggestion for a
possible future option.

A workaround that you could implement is to activate
iptables with a default DROP policy, open the firewall to
UDP/500, UDP/4500 and ESP, and then add static IPsec policy
iptables rules of the form:

iptables -A INPUT  -m policy --dir in  --pol ipsec --proto esp -j ACCEPT
iptables -A OUTPUT -m policy --dir out --pol ipsec --proto esp -j ACCEPT

Thus no plaintext packets should leave the VPN endpoint.

Regards

Andreas

On 29.07.2011 17:06, Patricia de Noriega wrote:
> How I can bind that interface by means of the ipsec.conf file?
> 
> Best regards,
> 
> On 29 July 2011 16:51, Andreas Steffen  > wrote:
> 
> Would it help to bind the virtual IP do a dummy interface, so that
> when the physical interface goes away the source route still
> exists and remains covered by the traffic selectors and thus by
> the transient DROP policy for the TS.
> 
> Regards
> 
> Andreas
> 
> On 07/29/2011 04:12 PM, Tobias Brunner wrote:
> > Hi Patricia,
> >
> >> I've test also with virtual IP's and I obtain the same behaviour :(
> >
> > Ah, yes.  The source route installed by charon only covers eth0
> and its
> > default gateway.
> >
> > Andreas, Martin, any ideas?
> >
> > Regards,
> > Tobias

==
Andreas Steffen andreas.stef...@strongswan.org
strongSwan - the Linux VPN Solution!www.strongswan.org
Institute for Internet Technologies and Applications
University of Applied Sciences Rapperswil
CH-8640 Rapperswil (Switzerland)
===[ITA-HSR]==

___
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users

Re: [strongSwan] MOBIKE

[Tobias Brunner]

> iptables -A INPUT  -m policy --dir in  --pol ipsec --proto esp -j ACCEPT
> iptables -A OUTPUT -m policy --dir out --pol ipsec --proto esp -j ACCEPT
>
> Thus no plaintext packets should leave the VPN endpoint.

That's probably the best solution for now.  The problem with the virtual 
IP approach is that the route has to be changed to the new interface, 
even when the IP is bound to a dummy interface.  And there we currently 
have the same delete/add race condition we had with the policies.

Regards,
Tobias


___
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users

Re: [strongSwan] MOBIKE

[Tobias Brunner]

Hi Patricia,

> Can this packet be tunneled at that point? are initiator and responder
> updating the SAs after the liveness test? I think this packet should not
> be received through the tunnel until the handover process ends.
>
> Is the return routability check activated by default? by who?

In the current implementation charon as the initiator of a MOBIKE 
exchange updates the IPsec SAs right after it determined a working 
address pair.  At the same time, it sends the address update which also 
includes a COOKIE2 payload, thus, is acting as routability check.  The 
responder only updates the addresses of the IPsec SAs after receiving an 
address update.  Since the observed ESP packet and the address update do 
not necessarily have to arrive in that order, it could very well be that 
the other peer successfully receives the ESP packet.

Regards,
Tobias

___
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users

Re: [strongSwan] MOBIKE

[Patricia de Noriega]

Hi again,

On 29 August 2011 17:56, Tobias Brunner  wrote:

> Hi Patricia,
>
>
>  Can this packet be tunneled at that point? are initiator and responder
>> updating the SAs after the liveness test? I think this packet should not
>> be received through the tunnel until the handover process ends.
>>
>> Is the return routability check activated by default? by who?
>>
>
> In the current implementation charon as the initiator of a MOBIKE exchange
> updates the IPsec SAs right after it determined a working address pair.  At
> the same time, it sends the address update which also includes a COOKIE2
> payload, thus, is acting as routability check.  The responder only updates
> the addresses of the IPsec SAs after receiving an address update.  Since the
> observed ESP packet and the address update do not necessarily have to arrive
> in that order, it could very well be that the other peer successfully
> receives the ESP packet.
>
>
Is that defined in the IKEv2 RFC? where? It is interesting that responders
could receive packets after update its IPsec SAs, but, if this is
standardized by any RFC maybe there is no need to send the
UPDATE_SA_ADDRESSES since the responder accepts every packet sent by the
initator.


Regards

Regards,
> Tobias
>
___
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users

Re: [strongSwan] MOBIKE

[Tobias Brunner]

Hi Patricia

>> In the current implementation charon as the initiator of a MOBIKE
>> exchange updates the IPsec SAs right after it determined a working
>> address pair.  At the same time, it sends the address update which
>> also includes a COOKIE2 payload, thus, is acting as routability
>> check.  The responder only updates the addresses of the IPsec SAs
>> after receiving an address update.  Since the observed ESP packet
>> and the address update do not necessarily have to arrive in that
>> order, it could very well be that the other peer successfully
>> receives the ESP packet.
>
> Is that defined in the IKEv2 RFC? where? It is interesting that
> responders could receive packets after update its IPsec SAs, but, if
> this is standardized by any RFC maybe there is no need to send the
> UPDATE_SA_ADDRESSES since the responder accepts every packet sent by the
> initator.

I'm not sure I completely understand your question.  Anyway, charon's 
behavior as described above is defined in RFC 4555 (MOBIKE), section 
3.5.  As far as the behavior for ESP traffic goes, this is handled by 
the Linux kernel.  For tunnel mode SAs the kernel currently accepts 
valid packets from any source.  But until the addresses in the kernel 
are updated the return path (outbound) will be invalid.  Traffic for 
transport mode SAs will be dropped, as the traffic selectors won't match 
until the addresses are update.  So the UPDATE_SA_ADDRESSES notification 
is definitely required (the addresses are not updated implicitly). 
Also, if the responder is multihomed and the initiator decides to use a 
different remote address, the ESP packets would also be dropped until 
the SAs are updated, because the kernel looks up IPsec SAs by SPI, 
protocol and destination address (i.e. the local address for inbound 
traffic).  I hope this answers your question.

Regards,
Tobias

___
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users

Re: [strongSwan] MOBIKE

[Patricia de Noriega]

Hello,

Is there any way to know the queue size employed on StrongSWAN? I've
observed that using the tunnel mode (using leftsubnet parameter) and
forcing a handover, few packets are lost (almost the same if I reduce the
packet size considerably. p.e. from 1300 bytes to 50 bytes) so I suppose
there exists a packet queue that keeps these packets until it is full. Can
the queue size be modified?

King regards
___
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users

Re: [strongSwan] MOBIKE + VTI

[Prashanth Venugopal]

Hi,

I am wondering if we could use the “listen” API provided in vici to get 
notified for “UPDATE_SA_ADDRESSES” events. But I am not sure what is the exact 
event type to register for.

Any help would be appreciated.

Thanks
Prashanth

From: Users  on behalf of Prashanth 
Venugopal 
Date: Thursday, November 30, 2017 at 1:18 AM
To: "users@lists.strongswan.org" 
Subject: [strongSwan] MOBIKE + VTI

Hi,

We have a use case where we need to support MOBIKE with VTI interfaces. S
Our Current solution involves using strongswan to provide the IKE protocol 
communication, but we disable route installs in Charon and add routes through 
our application code to point it to the appropriate VTI interfaces.

We want to do something similar for mobile clients (that use MOBIKE) but we 
would also like to cover the “UPDATE_SA_ADDRESSES” notification cases. In 
short, we would like to somehow figure out in our application (which uses the 
vici plugin to talk to strongswan) when an “UPDATE_SA_ADDRESSES” is received so 
that we can point the routes to a new/different vti interface.

I do see that strong swan does the path switching when it is taking care of 
routing, but is there a notification that the application could register for to 
catch this event and react appropriately with vti interfaces ?
Would the SA get deleted and re-created when this happens ?

Thanks
Prashanth

Re: [strongSwan] MOBIKE + VTI

[Prashanth Venugopal]

Hi Tobias et.al,

I was digging deeper to see if I can make this work (get notifications when an 
UPDATE_SA even happens in a MOBIKE connection).

From a brief reading of the ike_mobike.c file, it looks like strongswan delete 
the previous child_sa and creates a new one when an UPDATE_SA notification is 
received. I presume this will trigger a child_SA up_down notification through 
the vici plugin ?

I have been trying to create a scenario which triggers an UPDATE_SA using my 
android phone (native VPN client, Android version 7.0) to connect to a linux GW 
using strongswan as the responder, but have been unsuccessful in triggering 
this notification from the client.

However we would like to see if we can handle this situation gracefully in our 
code base (which uses strongswan with VTI tunnels). So any insight into the 
following topics would be much appreciated

  1.  The VICI trigger when an update_SA event is received on the responder.
  2.  A way to trigger the update_SA event from the mobile client (using native 
vpn support in android 7.0, just so that we can test easily with PSK auth).

Thanks
prashanth

From: Users  on behalf of Prashanth 
Venugopal 
Date: Thursday, November 30, 2017 at 10:44 AM
To: "users@lists.strongswan.org" 
Subject: Re: [strongSwan] MOBIKE + VTI

Hi,

I am wondering if we could use the “listen” API provided in vici to get 
notified for “UPDATE_SA_ADDRESSES” events. But I am not sure what is the exact 
event type to register for.

Any help would be appreciated.

Thanks
Prashanth

From: Users  on behalf of Prashanth 
Venugopal 
Date: Thursday, November 30, 2017 at 1:18 AM
To: "users@lists.strongswan.org" 
Subject: [strongSwan] MOBIKE + VTI

Hi,

We have a use case where we need to support MOBIKE with VTI interfaces. S
Our Current solution involves using strongswan to provide the IKE protocol 
communication, but we disable route installs in Charon and add routes through 
our application code to point it to the appropriate VTI interfaces.

We want to do something similar for mobile clients (that use MOBIKE) but we 
would also like to cover the “UPDATE_SA_ADDRESSES” notification cases. In 
short, we would like to somehow figure out in our application (which uses the 
vici plugin to talk to strongswan) when an “UPDATE_SA_ADDRESSES” is received so 
that we can point the routes to a new/different vti interface.

I do see that strong swan does the path switching when it is taking care of 
routing, but is there a notification that the application could register for to 
catch this event and react appropriately with vti interfaces ?
Would the SA get deleted and re-created when this happens ?

Thanks
Prashanth

Re: [strongSwan] MOBIKE & NAT traversal

[Andreas Steffen]

Hi Simo,

the MOBIKE protocol requires to always float the IKE port to UDP/4500
even if no NAT situation exists.

Section 3.3 of RFC 4555 clearly states:

   ... To
   simplify things, implementations that support both this specification
   and NAT Traversal MUST change to port 4500 if the correspondent also
   supports both, even if no NAT was detected between them (this way,
   there is no need to change the ports later if a NAT is detected on
   some other path).

If no actual NAT sitation is detected then strongSwan sets up the
IPsec SA so that it does no UDP encapsulation of the ESP packets
but you can enforce encapsulation by setting

  forceencaps=yes

in strongSwan's connection definition.

Best regards

Andreas

[EMAIL PROTECTED] wrote:
> Hi,
> 
> I'am doing a bit of experimenting on how StrongSwan performs as MOBIKE  
> enabled secure gateway. Currently I'am using StrongSwan 4.2.8 as my  
> gateway. (The client side is not a StrongSwan box.)
> 
> If the client side is behind NAT everything seems to work just fine.  
> The IKE traffic is moved to use port 4500 after IKE_SA_INIT and after  
> IKE_AUTH exchange the ESP traffic is also UDP encapsulated and uses  
> port 4500, as excepted. However, if there is not NAT between the  
> gateway and the client, the client side still moves the IKE and the  
> ESP traffic to use port 4500. At this point the StrongSwan box handles  
> the IKE traffic as expected but the ESP traffic is dropped.
> Is this kind of configuration supported in StrongSwan? (I mean UDP  
> encapsulation of ESP without NAT.)
> 
> Btw, Are these dropped ESP packets logged somewhere?
> 
>-Simo Bergman
> 
> ___
> Users mailing list
> Users@lists.strongswan.org
> https://lists.strongswan.org/mailman/listinfo/users


-- 
==
Andreas Steffen [EMAIL PROTECTED]
strongSwan - the Linux VPN Solution!www.strongswan.org

Institute for Internet Technologies and Applications
University of Applied Sciences Rapperswil
CH-8640 Rapperswil (Switzerland)
===[ITA-HSR]==

___
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users

Re: [strongSwan] MOBIKE & NAT traversal

[sbergman]

Hi,

Indeed it is clear that the IKE traffic has to be moved to the port  
4500 if MOBIKE is used. But should the ESP traffic be encapsulated or  
not, is bit unclear. My interpretation is that, if there is no NAT  
between the client and SGW the client can still use the UDP  
encapsulation for IPSec data.
(http://www.machshav.com/pipermail/mobike/2006-September/001491.html).

At this point it seems to be that the StrongSwan assumes that no UDP  
encapsulation is done, if there is no actual NAT between the hosts. If  
the client sends the ESP data using UDP encapsulation the ESP packets  
are dropped.
(In my case StrongSwan is always a responder.)

Is this a correct assumption?

The parameter forceencaps=yes does not seems to have any affect.
My whole configuration looks like this:

config setup
# plutodebug=all
# crlcheckinterval=600
# strictcrlpolicy=yes
# cachecrls=yes
nat_traversal=yes
# charonstart=no
plutostart=no

# Add connections here.
conn %default
  keyexchange=ikev2
  left=192.168.75.50
  leftsubnet=10.0.0.0/24

conn ia-string-format-psk
  authby=secret
  [EMAIL PROTECTED]
  right=%any
  forceencaps=yes
  rightsourceip=10.0.0.15
  rightsubnet=10.0.0.0/24
  auto=add

   -Br
Simo Bergman


Quoting Andreas Steffen <[EMAIL PROTECTED]>:

> Hi Simo,
>
> the MOBIKE protocol requires to always float the IKE port to UDP/4500
> even if no NAT situation exists.
>
> Section 3.3 of RFC 4555 clearly states:
>
>... To
>simplify things, implementations that support both this specification
>and NAT Traversal MUST change to port 4500 if the correspondent also
>supports both, even if no NAT was detected between them (this way,
>there is no need to change the ports later if a NAT is detected on
>some other path).
>
> If no actual NAT sitation is detected then strongSwan sets up the
> IPsec SA so that it does no UDP encapsulation of the ESP packets
> but you can enforce encapsulation by setting
>
>   forceencaps=yes
>
> in strongSwan's connection definition.
>
> Best regards
>
> Andreas
>
> [EMAIL PROTECTED] wrote:
>> Hi,
>>
>> I'am doing a bit of experimenting on how StrongSwan performs as MOBIKE
>> enabled secure gateway. Currently I'am using StrongSwan 4.2.8 as my
>> gateway. (The client side is not a StrongSwan box.)
>>
>> If the client side is behind NAT everything seems to work just fine.
>> The IKE traffic is moved to use port 4500 after IKE_SA_INIT and after
>> IKE_AUTH exchange the ESP traffic is also UDP encapsulated and uses
>> port 4500, as excepted. However, if there is not NAT between the
>> gateway and the client, the client side still moves the IKE and the
>> ESP traffic to use port 4500. At this point the StrongSwan box handles
>> the IKE traffic as expected but the ESP traffic is dropped.
>> Is this kind of configuration supported in StrongSwan? (I mean UDP
>> encapsulation of ESP without NAT.)
>>
>> Btw, Are these dropped ESP packets logged somewhere?
>>
>>-Simo Bergman
>>
>> ___
>> Users mailing list
>> Users@lists.strongswan.org
>> https://lists.strongswan.org/mailman/listinfo/users
>
>
> --
> ==
> Andreas Steffen [EMAIL PROTECTED]
> strongSwan - the Linux VPN Solution!www.strongswan.org
>
> Institute for Internet Technologies and Applications
> University of Applied Sciences Rapperswil
> CH-8640 Rapperswil (Switzerland)
> ===[ITA-HSR]==
>
> ___
> Users mailing list
> Users@lists.strongswan.org
> https://lists.strongswan.org/mailman/listinfo/users
>



___
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users

Re: [strongSwan] MOBIKE & NAT traversal

[Martin Willi]

Hi,

> At this point it seems to be that the StrongSwan assumes that no UDP  
> encapsulation is done, if there is no actual NAT between the hosts.

Yes, we strictly enable/disable UDP depending on the NAT situation. It
is updated if a peer moves into/outof a NAT router. The forceencaps
parameter even simulates a NAT situation by faking the NAT payloads
(which is required anyway to force the peer to use UDP encap).

I actually don't know if it is possible to accept both, encapsulated and
not encapsulated packets in the kernel, I'll have to try that.

> My interpretation is that, if there is no NAT  
> between the client and SGW the client can still use the UDP  
> encapsulation for IPSec data.

This is not the behavior we currently implemented. But you're right,
draft-ietf-ipsecme-ikev2bis-01 p58 clearly states:

> o  Implementations MUST process received UDP-encapsulated ESP packets
>   even when no NAT was detected.

I'll try to fix this.

Regards
Martin


___
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users

Re: [strongSwan] MOBIKE & NAT traversal

[Martin Willi]

Hi,

> > o  Implementations MUST process received UDP-encapsulated ESP packets
> >   even when no NAT was detected.
> 
> I'll try to fix this.

I've fixed this problem in the kernel, a patch [1] is gone upstream. We
still enable/disable UDP-Encapsulation strictly depending on the NAT
situation, but incoming packets are accepted regardless of the used
encapsulation mode.

Regards
Martin

[1]http://kerneltrap.org/mailarchive/linux-netdev/2008/12/4/4312604


___
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users

Re: [strongSwan] MOBIKE & NAT traversal

[Martin Willi]

Hi Simo,

> [1]http://kerneltrap.org/mailarchive/linux-netdev/2008/12/4/4312604

My patch introduced a bug and therefore has been reverted upstream.

Additionally, there are some doubts if encapsulated packets should be
processed if it is not explicitly enabled in the SA. You might join the
discussion (above) and explain why and in which situation this would
make sense. Herbert asked for your client OS/Daemon.

In the meantime, I'll do some testing with a modified patch that accepts
encapsulated packets on a non-encapsulating SA, but not vice-versa.

Regards
Martin


___
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users

Re: [strongSwan] MOBIKE & NAT traversal

[Herbert Xu]

On Fri, Dec 19, 2008 at 11:00:22AM +0100, Martin Willi wrote:
>
> Additionally, there are some doubts if encapsulated packets should be
> processed if it is not explicitly enabled in the SA. You might join the
> discussion (above) and explain why and in which situation this would
> make sense. Herbert asked for your client OS/Daemon.

Simo, are you doing MOBIKE?

Does MOBIKE require UDP encapsulation regardless of NAT? If so
what Strongswan should do is always enable UDP encapsulation if
it detects MOBIKE.

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
___
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users

Re: [strongSwan] MOBIKE & NAT traversal

[sbergman]

Hi,

I'm doing a bit of MOBIKE development whenever I have extra time. So  
my experience in MOBIKE is still somewhat limited.

I think the problem is that the RFC 4555 is unclear.

The RFC says:
3.3.  Initial Tunnel Header Addresses

When an IPsec SA is created, the tunnel header IP addresses (and
port, if doing UDP encapsulation) are taken from the IKE_SA, not the
IP header of the IKEv2 message requesting the IPsec SA.  The
addresses in the IKE_SA are initialized from the IP header of the
first IKE_AUTH request.

How I see this is that, if first IKE_AUTH uses port 4500, then the ESP  
packets have to be UDP encapsulated. Then the same chapter continues:

The addresses are taken from the IKE_AUTH request because IKEv2
requires changing from port 500 to 4500 if a NAT is discovered.  To
simplify things, implementations that support both this specification
and NAT Traversal MUST change to port 4500 if the correspondent also
supports both, even if no NAT was detected between them (this way,
there is no need to change the ports later if a NAT is detected on
some other path).

Which effectively says that the MOBIKE capable implementation have use  
port 4500, when sending IKE_AUTH request.
Then there is this mail conversation about this:
http://www.machshav.com/pipermail/mobike/2006-September/001491.html,  
which at least tries to bring some clarity to this issue.

In my opinion the result of all this is that this will probably cause  
interoperability problems also in the future. (The right think would  
be to fix the RFC so, that it clearly specifies when the UDP  
encapsulation has to be used and when not.) For me the lesson learned  
is, that I have to change my implementation to use UDP encapsulation  
for outgoing traffic only, when the NAT is present. But I will accept  
UDP encapsulated incoming ESP packets even though there is no NAT  
between the peers. I don't think this is an elegant solution, but then  
I hopefully have inter. op. with most of the MOBIKE implementations.
I really can't say should StrongSwan also use this approach or not. I  
have to left it to you to decide. ;)

   Merry Christmas to all
  Simo Bergman


Quoting Herbert Xu :

> On Fri, Dec 19, 2008 at 11:00:22AM +0100, Martin Willi wrote:
>>
>> Additionally, there are some doubts if encapsulated packets should be
>> processed if it is not explicitly enabled in the SA. You might join the
>> discussion (above) and explain why and in which situation this would
>> make sense. Herbert asked for your client OS/Daemon.
>
> Simo, are you doing MOBIKE?
>
> Does MOBIKE require UDP encapsulation regardless of NAT? If so
> what Strongswan should do is always enable UDP encapsulation if
> it detects MOBIKE.
>
> Cheers,
> --
> Visit Openswan at http://www.openswan.org/
> Email: Herbert Xu ~{PmV>HI~} 
> Home Page: http://gondor.apana.org.au/~herbert/
> PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
>



___
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users

Re: [strongSwan] MOBIKE break-before-make case

[Martin Willi]

Hi,

> [...] more precisely break-before-make case.

Break-before-make support is currently somewhat limited. While it should
work, strongSwan has a rather short timeout before dropping the SA. If
it can't update the SA withing 30 seconds or so, the SA gets deleted.

> Is this case supported/implemented in strongSwan this far? How to configure 
> it?

There is no way to configure MOBIKE behavior, it just tries to keep the
SA up using the routes configured in the kernel.

Regards
Martin

___
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users

Re: [strongSwan] Mobike problem and route table 220

[Adam French]

Hi,
Here is some more detail on my test case.  As can be seen, the route in
table 220 on bart (alice's equivalent) is empty after the switch.  The
route on table 220 on homer has been updated.  
Any information would be much appreciated.
Many thanks,
Adam French.


  |--|-10.0.1.100---10.0.1.1-[GW1]-192.168.3.83---|
|---|
172.22.0.1/24 | bart |
--192.168.2.146-| homer |-172.22.100.1/24
  |--|-10.0.2.100---10.0.2.1-[GW2]-192.168.2.90---|
|---|

Starting Condition:
r...@bart:~$ route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric RefUse
Iface
10.0.1.00.0.0.0 255.255.255.0   U 0  00
eth1
10.0.2.00.0.0.0 255.255.255.0   U 0  00
eth2
172.22.0.0  0.0.0.0 255.255.255.0   U 0  00
eth0
0.0.0.0 10.0.1.10.0.0.0 UG0  00
eth1
r...@bart:~$ ipsec status
Security Associations:
  mobike[1]: ESTABLISHED,
10.0.1.100[192.168.2.60]...192.168.2.146[192.168.2.146]
  mobike{1}:  ROUTED, TUNNEL
  mobike{1}:   172.22.0.0/24 === 172.22.100.0/24
  mobike{2}:  INSTALLED, TUNNEL, ESP in UDP SPIs: c07a911c_i
c505959d_o
  mobike{2}:   172.22.0.0/24 === 172.22.100.0/24
r...@bart:~$ ip route list table 220
172.22.100.0/24 via 10.0.1.1 dev eth1  proto static  src 172.22.0.1
r...@homer:/# ipsec status
Security Associations:
  mobike[2]: ESTABLISHED,
192.168.2.146[192.168.2.146]...192.168.3.83[192.168.2.60]
  mobike{2}:  INSTALLED, TUNNEL, ESP in UDP SPIs: c505959d_i
c07a911c_o
  mobike{2}:   172.22.100.0/24 === 172.22.0.0/24
r...@homer:/# ip route list table 220
172.22.0.0/24 via 192.168.3.83 dev br0  proto static  src 172.22.100.1


Switch test method:
r...@bart:~# route del -net 0.0.0.0/0 gw 10.0.1.1
r...@bart:~# route add -net 0.0.0.0/0 gw 10.0.2.1
r...@bart:~# ifconfig eth1 down


Post Test Condition:
r...@homer:~# ipsec status
Security Associations:
  mobike[2]: ESTABLISHED,
192.168.2.146[192.168.2.146]...192.168.2.90[192.168.2.60]
  mobike{2}:  INSTALLED, TUNNEL, ESP in UDP SPIs: c505959d_i
c07a911c_o
  mobike{2}:   172.22.100.0/24 === 172.22.0.0/24
r...@homer:~# ip route list table 220
172.22.0.0/24 via 192.168.2.90 dev br0  proto static  src 172.22.100.1
r...@bart:~# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric RefUse
Iface
10.0.2.00.0.0.0 255.255.255.0   U 0  00
eth2
172.22.0.0  0.0.0.0 255.255.255.0   U 0  00
eth0
0.0.0.0 10.0.2.10.0.0.0 UG0  00
eth2
r...@bart:/# ipsec status
Security Associations:
  mobike[1]: ESTABLISHED,
10.0.2.100[192.168.2.60]...192.168.2.146[192.168.2.146]
  mobike{1}:  ROUTED, TUNNEL
  mobike{1}:   172.22.0.0/24 === 172.22.100.0/24
  mobike{2}:  INSTALLED, TUNNEL, ESP in UDP SPIs: c07a911c_i
c505959d_o
  mobike{2}:   172.22.0.0/24 === 172.22.100.0/24
r...@bart:~# ip route list table 220
r...@bart:~#
/var/log/daemon.log on bart
Dec 16 09:57:54 bart charon: 05[KNL] interface eth1 deactivated
Dec 16 09:57:54 bart charon: 05[KNL] fe80::a00:27ff:feaa:789a
disappeared from eth1
Dec 16 09:57:54 bart charon: 12[IKE] requesting address change using
MOBIKE
Dec 16 09:57:54 bart charon: 12[ENC] generating INFORMATIONAL request 2
[ N(ADD_4_ADDR) N(ADD_4_ADDR) ]
Dec 16 09:57:54 bart charon: 12[IKE] checking path 10.0.2.100[4500] -
172.22.100.1[4500]
Dec 16 09:57:54 bart charon: 12[NET] sending packet: from
10.0.2.100[4500] to 172.22.100.1[4500]
Dec 16 09:57:54 bart charon: 12[IKE] checking path 10.0.2.100[4500] -
172.22.200.0[4500]
Dec 16 09:57:54 bart charon: 12[NET] sending packet: from
10.0.2.100[4500] to 172.22.200.0[4500]
Dec 16 09:57:54 bart charon: 12[IKE] checking path 10.0.2.100[4500] -
192.168.2.146[4500]
Dec 16 09:57:54 bart charon: 12[NET] sending packet: from
10.0.2.100[4500] to 192.168.2.146[4500]
Dec 16 09:57:54 bart charon: 10[NET] received packet: from
192.168.2.146[4500] to 10.0.2.100[4500]
Dec 16 09:57:54 bart charon: 10[ENC] parsed INFORMATIONAL response 2 [ ]
Dec 16 09:57:54 bart charon: 10[ENC] generating INFORMATIONAL request 3
[ N(UPD_SA_ADDR) N(NATD_S_IP) N(NATD_D_IP) N(COOKIE2) ]
Dec 16 09:57:54 bart charon: 10[NET] sending packet: from
10.0.2.100[4500] to 192.168.2.146[4500]
Dec 16 09:57:54 bart charon: 09[NET] received packet: from
192.168.2.146[4500] to 10.0.2.100[4500]
Dec 16 09:57:54 bart charon: 09[ENC] parsed INFORMATIONAL response 3 [
N(NATD_S_IP) N(NATD_D_IP) N(COOKIE2) ]

/var/log/daemon.log on homer
Dec 16 09:57:54 homer charon: 12[NET] received packet: from
192.168.2.90[4500] to 192.168.2.146[4500]
Dec 16 09:57:54 homer charon: 12[ENC] parsed INFORMATIONAL request 2 [
N(ADD_4_ADDR) N(ADD_4_ADDR) ]
Dec 16 09:57:54 homer charon: 12[ENC] generating INFORMATIONAL response
2 [ ]
Dec 16 09:57:54 homer charon: 12[NET] sending packet: from
192.168.2.146[4500] to 192.

Re: [strongSwan] Mobike problem and route table 220

[Adam French]

 
I seem to have solved the problem by setting 
left=%defaultroute 
On bart (alice) 
Previously it had been set to letf=%any 
Now the route in table 220 is being updated correctly.
Thanks for the great work developing and maintaining this program!!!
Adam French



-Original Message-
From: users-boun...@lists.strongswan.org
[mailto:users-boun...@lists.strongswan.org] On Behalf Of Adam French
Sent: Tuesday, December 16, 2008 10:13 AM
To: users@lists.strongswan.org
Subject: Re: [strongSwan] Mobike problem and route table 220

Hi,
Here is some more detail on my test case.  As can be seen, the route in
table 220 on bart (alice's equivalent) is empty after the switch.  The
route on table 220 on homer has been updated.  
Any information would be much appreciated.
Many thanks,
Adam French.


  |--|-10.0.1.100---10.0.1.1-[GW1]-192.168.3.83---|
|---|
172.22.0.1/24 | bart |
--192.168.2.146-| homer |-172.22.100.1/24
  |--|-10.0.2.100---10.0.2.1-[GW2]-192.168.2.90---|
|---|

Starting Condition:
r...@bart:~$ route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric RefUse
Iface
10.0.1.00.0.0.0 255.255.255.0   U 0  00
eth1
10.0.2.00.0.0.0 255.255.255.0   U 0  00
eth2
172.22.0.0  0.0.0.0 255.255.255.0   U 0  00
eth0
0.0.0.0 10.0.1.10.0.0.0 UG0  00
eth1
r...@bart:~$ ipsec status
Security Associations:
  mobike[1]: ESTABLISHED,
10.0.1.100[192.168.2.60]...192.168.2.146[192.168.2.146]
  mobike{1}:  ROUTED, TUNNEL
  mobike{1}:   172.22.0.0/24 === 172.22.100.0/24
  mobike{2}:  INSTALLED, TUNNEL, ESP in UDP SPIs: c07a911c_i
c505959d_o
  mobike{2}:   172.22.0.0/24 === 172.22.100.0/24
r...@bart:~$ ip route list table 220
172.22.100.0/24 via 10.0.1.1 dev eth1  proto static  src 172.22.0.1
r...@homer:/# ipsec status
Security Associations:
  mobike[2]: ESTABLISHED,
192.168.2.146[192.168.2.146]...192.168.3.83[192.168.2.60]
  mobike{2}:  INSTALLED, TUNNEL, ESP in UDP SPIs: c505959d_i
c07a911c_o
  mobike{2}:   172.22.100.0/24 === 172.22.0.0/24
r...@homer:/# ip route list table 220
172.22.0.0/24 via 192.168.3.83 dev br0  proto static  src 172.22.100.1


Switch test method:
r...@bart:~# route del -net 0.0.0.0/0 gw 10.0.1.1
r...@bart:~# route add -net 0.0.0.0/0 gw 10.0.2.1
r...@bart:~# ifconfig eth1 down


Post Test Condition:
r...@homer:~# ipsec status
Security Associations:
  mobike[2]: ESTABLISHED,
192.168.2.146[192.168.2.146]...192.168.2.90[192.168.2.60]
  mobike{2}:  INSTALLED, TUNNEL, ESP in UDP SPIs: c505959d_i
c07a911c_o
  mobike{2}:   172.22.100.0/24 === 172.22.0.0/24
r...@homer:~# ip route list table 220
172.22.0.0/24 via 192.168.2.90 dev br0  proto static  src 172.22.100.1
r...@bart:~# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric RefUse
Iface
10.0.2.00.0.0.0 255.255.255.0   U 0  00
eth2
172.22.0.0  0.0.0.0 255.255.255.0   U 0  00
eth0
0.0.0.0 10.0.2.10.0.0.0 UG0  00
eth2
r...@bart:/# ipsec status
Security Associations:
  mobike[1]: ESTABLISHED,
10.0.2.100[192.168.2.60]...192.168.2.146[192.168.2.146]
  mobike{1}:  ROUTED, TUNNEL
  mobike{1}:   172.22.0.0/24 === 172.22.100.0/24
  mobike{2}:  INSTALLED, TUNNEL, ESP in UDP SPIs: c07a911c_i
c505959d_o
  mobike{2}:   172.22.0.0/24 === 172.22.100.0/24
r...@bart:~# ip route list table 220
r...@bart:~#
/var/log/daemon.log on bart
Dec 16 09:57:54 bart charon: 05[KNL] interface eth1 deactivated
Dec 16 09:57:54 bart charon: 05[KNL] fe80::a00:27ff:feaa:789a
disappeared from eth1
Dec 16 09:57:54 bart charon: 12[IKE] requesting address change using
MOBIKE
Dec 16 09:57:54 bart charon: 12[ENC] generating INFORMATIONAL request 2
[ N(ADD_4_ADDR) N(ADD_4_ADDR) ]
Dec 16 09:57:54 bart charon: 12[IKE] checking path 10.0.2.100[4500] -
172.22.100.1[4500]
Dec 16 09:57:54 bart charon: 12[NET] sending packet: from
10.0.2.100[4500] to 172.22.100.1[4500]
Dec 16 09:57:54 bart charon: 12[IKE] checking path 10.0.2.100[4500] -
172.22.200.0[4500]
Dec 16 09:57:54 bart charon: 12[NET] sending packet: from
10.0.2.100[4500] to 172.22.200.0[4500]
Dec 16 09:57:54 bart charon: 12[IKE] checking path 10.0.2.100[4500] -
192.168.2.146[4500]
Dec 16 09:57:54 bart charon: 12[NET] sending packet: from
10.0.2.100[4500] to 192.168.2.146[4500]
Dec 16 09:57:54 bart charon: 10[NET] received packet: from
192.168.2.146[4500] to 10.0.2.100[4500]
Dec 16 09:57:54 bart charon: 10[ENC] parsed INFORMATIONAL response 2 [ ]
Dec 16 09:57:54 bart charon: 10[ENC] generating INFORMATIONAL request 3
[ N(UPD_SA_ADDR) N(NATD_S_IP) N(NATD_D_IP) N(COOKIE2) ]
Dec 16 09:57:54 bart charon: 10[NET] sending packet: from
10.0.2.100[4500] to 192.168.2.146[4500]
Dec 16 09:57:54 bart charon: 09[NET] received packet:

Re: [strongSwan] Mobike on strongswan MAC OSX Client

[Tobias Brunner]

Hi Pankaj,

> I am facing issue with strongswan MAC OS X client which I have compiled
> from source. 
> 
> version
> --
> Starting IKE charon daemon (strongSwan 5.7.2dr2, Linux
> 4.15.0-112-generic, x86_64)

That seems to contradict what you wrote above (Linux != macOS).  And why
use an old developers release?

> I am able to connect to server in road warrior scenario. When I switch
> wifi on my MAC laptop, source outer IP address (192.168.1.5) does not
> change for IKE SA.

If the "old" address is still available and a route leads to it, nothing
will change unless you force the daemon to ignore the current path by
enabling charon.prefer_best_path (depending on the routes, the path
might still not change).

Regards,
Tobias

Re: [strongSwan] Mobike on strongswan MAC OSX Client

[pankaj razdan]

 Hi Tobias,
Thanks you for your response. 
Please see my response inline below.
Thanks,Pankaj
> I am facing issue with strongswan MAC OS X client which I have compiled
> from source. 
> 
> version
> --
> Starting IKE charon daemon (strongSwan 5.7.2dr2, Linux
> 4.15.0-112-generic, x86_64)

That seems to contradict what you wrote above (Linux != macOS).  And why
use an old developers release?
 Sorry my bad. I copied from linux system rather than from MAC. We have 
ported this version to both linux and MAC. We are planning to move to latest 
version in this quarter. There were few vpp plugins which we could leverage 
from this release.


> I am able to connect to server in road warrior scenario. When I switch
> wifi on my MAC laptop, source outer IP address (192.168.1.5) does not
> change for IKE SA.

If the "old" address is still available and a route leads to it, nothing
will change unless you force the daemon to ignore the current path by
enabling charon.prefer_best_path (depending on the routes, the path
might still not change).
 Thank you. I made this change in strongswan.conf, it still did not work. 
So I changed route based on "new" address from CLI (route change cmd), then I 
could see outer IP changed to "new" IP. However, I could not see these packets 
in wireshark capture.
Jul 29 14:33:37 02[NET] error writing to socket: Can’t assign requested 
addressJul 29 14:33:37 14[IKE]  path probing attempt 8Jul 29 14:33:37 
14[IKE]  ExC: get_source_addr for dst 32.2.4.18, src (null)Jul 29 
14:33:37 14[IKE]  ExC: get_route,   192.168.1.112
Jul 29 14:33:37 14[KNL]  using 192.168.1.112 as address to reach 
32.2.4.18Jul 29 14:33:37 14[IKE]  checking path 192.168.1.112[4500] - 
32.2.4.18[4500]Jul 29 14:33:37 14[NET]  sending packet: sock: from 
192.168.1.112[4500] to 32.2.4.18[4500] (96 bytes)Jul 29 14:33:37 14[IKE] 
 ExC: get_source_addr for dst 192.168.124.100, src (null)Jul 29 
14:33:37 14[IKE]  ExC: get_route
I was wondering whether my approach is wrong or it is more of the system issue 
I am facing. All I am doing is switching wifi on my machine to test Mobike.

Regards,Pankaj

On Wednesday, July 29, 2020, 01:26:47 PM GMT+5:30, Tobias Brunner 
 wrote:  
 
 Hi Pankaj,

> I am facing issue with strongswan MAC OS X client which I have compiled
> from source. 
> 
> version
> --
> Starting IKE charon daemon (strongSwan 5.7.2dr2, Linux
> 4.15.0-112-generic, x86_64)

That seems to contradict what you wrote above (Linux != macOS).  And why
use an old developers release?

> I am able to connect to server in road warrior scenario. When I switch
> wifi on my MAC laptop, source outer IP address (192.168.1.5) does not
> change for IKE SA.

If the "old" address is still available and a route leads to it, nothing
will change unless you force the daemon to ignore the current path by
enabling charon.prefer_best_path (depending on the routes, the path
might still not change).

Regards,
Tobias
  

Re: [strongSwan] MOBIKE task got stuck Strongswan version 5.3.2

[Tobias Brunner]

Hi Simon,

> 1. Any guesses on how MOBIKE task get stuck and won't timeout? Should
> there be on-going re-tries?

Read the log.

> 2. I think charon is still sending keepalive messages to the peers with
> MOBIKE task active, but no DPD is sent. This behavior seems to create
> the situation that tunnels stay connect but they are really dead long ago.

Could be the daemon thinks there is no valid path to reach the peer, so
it deferred sending any messages until the network connectivity changes
(again check the log for details).

> 3. Following Q2, DPD won't do any good because the MOBIKE task seems to
> have higher priority then delete. Is this behavior fixed in 5.5 recently
> (issues/1410)?

That issue is related to IKEv1.  The idea behind preferring MOBIKE tasks
over others is that without a valid path to the peer there is no point
in sending other messages and if the peer can't be reached, the MOBIKE
exchange, whether it is an update or a DPD, will trigger the DPD action
anyway.

> 4. I need to support remote devices doing MOBIKE switch but I don't want
> the VPN server in the office to perform MOBIKE switch. It is futile.
> There is no secondary internet interface to switch to. Chaos ensure when
> charon tries to find alternate paths on a 1000 tunnels.

The MOBIKE task does not necessarily mean that this is an actual MOBIKE
update.  With MOBIKE enabled between two peers DPDs are also handled by
these tasks.

> Can development team
> members point out where I can tweak the source code to silently ignore
> MOBIKE jobs? If I put mobike=no in ipsec.conf I think remote peers won't
> be able to do MOBIKE switch.

If the MOBIKE task is actually triggered by a network change you can
avoid that by disabling charon.plugins.kernel-netlink.roam_events.

Regards,
Tobias

___
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users

Re: [strongSwan] MOBIKE task got stuck Strongswan version 5.3.2

[Simon Chan]

Hi Tobias,

After customer added roam_events = no in config file,
problem still occurs on most of the tunnels.
It would seems MOBIKE tasks are not caused by interface up/down.
Can you tell what events can trigger activation of MOBIKE task?

I saw these in customer's syslog:

   - sending DPD request
   - generating INFORMATIONAL request 0 [ N(NATD_S_IP) N(NATD_D_IP) ]
   - no route found to reach peer, MOBIKE update deferred

I cannot reproduce such exchange in my lab. I got these logs:

   - sending DPD request
   - activating IKE_DPD task (may come from my own debug prints)
   - generating INFORMATION request 0 [ ]
   - sending packet: from  to 

Thanks,

Simon



On Fri, May 5, 2017 at 2:20 AM, Tobias Brunner 
wrote:

> Hi Simon,
>
> > 1. Any guesses on how MOBIKE task get stuck and won't timeout? Should
> > there be on-going re-tries?
>
> Read the log.
>
> > 2. I think charon is still sending keepalive messages to the peers with
> > MOBIKE task active, but no DPD is sent. This behavior seems to create
> > the situation that tunnels stay connect but they are really dead long
> ago.
>
> Could be the daemon thinks there is no valid path to reach the peer, so
> it deferred sending any messages until the network connectivity changes
> (again check the log for details).
>
> > 3. Following Q2, DPD won't do any good because the MOBIKE task seems to
> > have higher priority then delete. Is this behavior fixed in 5.5 recently
> > (issues/1410)?
>
> That issue is related to IKEv1.  The idea behind preferring MOBIKE tasks
> over others is that without a valid path to the peer there is no point
> in sending other messages and if the peer can't be reached, the MOBIKE
> exchange, whether it is an update or a DPD, will trigger the DPD action
> anyway.
>
> > 4. I need to support remote devices doing MOBIKE switch but I don't want
> > the VPN server in the office to perform MOBIKE switch. It is futile.
> > There is no secondary internet interface to switch to. Chaos ensure when
> > charon tries to find alternate paths on a 1000 tunnels.
>
> The MOBIKE task does not necessarily mean that this is an actual MOBIKE
> update.  With MOBIKE enabled between two peers DPDs are also handled by
> these tasks.
>
> > Can development team
> > members point out where I can tweak the source code to silently ignore
> > MOBIKE jobs? If I put mobike=no in ipsec.conf I think remote peers won't
> > be able to do MOBIKE switch.
>
> If the MOBIKE task is actually triggered by a network change you can
> avoid that by disabling charon.plugins.kernel-netlink.roam_events.
>
> Regards,
> Tobias
>
>

Re: [strongSwan] MOBIKE task got stuck Strongswan version 5.3.2

[Tobias Brunner]

Hi Simon,

> It would seems MOBIKE tasks are not caused by interface up/down.
> Can you tell what events can trigger activation of MOBIKE task?

As I already wrote DPDs are also handled by MOBIKE tasks if both peers
support MOBIKE.  You could disable MOBIKE in the config if you don't
want to use it at all.

Regards,
Tobias

Re: [strongSwan] MOBIKE switching bug in gateway with two external interfaces

[Simon Chan]

Greetings,

Just plowed through RFC 4555 and 4621 for guidance. The spec says put the 
currently used address in the IP header
and the rest as additional addresses. Thus excluding "me" in the 
additional_addresses list is correct.

But there is this sentence in rfc4621, section 6.4:

"To support NAT-T, the IP addresses of the received packet are considered as 
one address of the peer, even when they are not present in the list."

Seems MOBIKE message processing needs to store the message's source IP addr 
along with the other ADDITIONAL_IPV4_ADDRESS. Use ike_sa to "remember" this 
address separately is not safe. It requires

code to add it in the additional_addresses list before it is overwritten by 
N(UPDATE_SA_ADDRESSES).

Regards,
Simon





 
To verify this theory, we made the following change in ike_mobike.c:


if (first)
{  /* an
 ADDITIONAL_*_ADDRESS means replace, so flush once */
this->ike_sa->remove_additional_addresses(this->ike_sa);
first = FALSE;

// Added code to seed the IP address in SA in the additional_address list
host = this->ike_sa->get_other_host(this->ike_sa);
host = host->clone(host);
this->ike_sa->add_additional_address(this->ike_sa, host);
}

After applying this change to a road warrior, it can switch back and forth 
between the 2 interfaces.

Questions:
1. Is there reason why the peer IP address in the Security Association not 
stored in the additional_address list?
2. Can anyone see potential problems with the code change above? 
Not sure if there may be situations when ike_sa->get_other_host() may not 
return the correct gateway address.
The change tested OK in our lab though.
3. Another possibility
 is to change the gateway side to include "me" in the Mobike additional 
addresses.
It is easier to upgrade one host than upgrading a fleet of 800 trucks. Similar 
to Question 1, is there
reason that "me" must be excluded from the Mobike additional addresses?

Thanks in advance for help.
Simon ___
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users

Re: [strongSwan] MOBIKE switching bug in gateway with two external interfaces

[Tobias Brunner]

Hi Simon,

> Seems MOBIKE message processing needs to store the message's source IP
> addr along with the other ADDITIONAL_IPV4_ADDRESS. Use ike_sa to
> "remember" this address separately is not safe. It requires
> code to add it in the additional_addresses list before it is overwritten
> by N(UPDATE_SA_ADDRESSES).

You are right, we should store the peer's current address in this list.
 I pushed some commits to our repository to fix this (see [1]-[4]).

Regards,
Tobias

[1] http://git.strongswan.org/?p=strongswan.git;a=commitdiff;h=2fe624cc
[2] http://git.strongswan.org/?p=strongswan.git;a=commitdiff;h=94bbc602
[3] http://git.strongswan.org/?p=strongswan.git;a=commitdiff;h=72b28112
[4] http://git.strongswan.org/?p=strongswan.git;a=commitdiff;h=cd6b5bf8


___
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users

Re: [strongSwan] MOBIKE switching bug in gateway with two external interfaces

[Simon Chan]

Hi Tobias,

Wow! I just posted the problem yesterday and the fix is ready this morning.
Much appreciate your effort.


Simon



 From: Tobias Brunner 
To: Simon Chan  
Cc: "users@lists.strongswan.org"  
Sent: Friday, March 9, 2012 1:38:33 AM
Subject: Re: [strongSwan] MOBIKE switching bug in gateway with two external 
interfaces
 
Hi Simon,

> Seems MOBIKE message processing needs to store the message's source IP
> addr along with the other ADDITIONAL_IPV4_ADDRESS. Use ike_sa to
> "remember" this address separately is not safe. It requires
> code to add it in the additional_addresses list before it is overwritten
> by N(UPDATE_SA_ADDRESSES).

You are right, we should store the peer's current address in this list.
I pushed some commits to our repository to fix this (see [1]-[4]).

Regards,
Tobias

[1] http://git.strongswan.org/?p=strongswan.git;a=commitdiff;h=2fe624cc
[2] http://git.strongswan.org/?p=strongswan.git;a=commitdiff;h=94bbc602
[3] http://git.strongswan.org/?p=strongswan.git;a=commitdiff;h=72b28112
[4] http://git.strongswan.org/?p=strongswan.git;a=commitdiff;h=cd6b5bf8___
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users