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
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
Hello,
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)
---
I am able to connect to server in road warrior scenario. When I switch wifi on
my M
Hello
? where can I find information on MOBIKE routing path selection (descripted in
this reference)
https://wiki.strongswan.org/projects/strongswan/repository/revisions/597e8c9e009946c994fcba525bacc647f46bae60
, 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.
: 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 dis
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 interface
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
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 reques
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 tun
Greetings,
One of our remote devices was broken and gone offline a month ago. Couple
days ago when we tried to bring up the replacement, failed to setup child
because the subnets were (and still are) in use.
ipsec status shows:
. . .
originalclient[4099]: ESTABLISHED 33 days ago,
10.1.1.1[10.1.1.
Hi Amit,
> Here I expect client to send UPDATE_SA_ADDRESS notification for new IP
> address 85.1.96.159 before actually start using this new IP address.
> However, client start sending DPD messages using new IP
> to which CISCO GW is not responding (As GW is not aware of new IP
> address)
And why
Hi All,
I'm testing MOBIKE feature with CISCO GW and strongswan client. Please find
below the test set-up details.
Strongswan-->CISCO GW
85.1.96.13385.1.96.205
85.1.96.159
I've configured two interfaces on the client side in the 85 VLAN and
testing the MOBIK
Hi,
I installed and build strongswan on my Android device and I have been
trying to switch my device between 2 WLANs requiring tunnel setup on WLAN_2
but not on WLAN_1. Following diagram explains my setup. Generally the
transition is smooth between the WLANs but occasionally, I encounter some
mobi
Good day.
Seems that charon does not change table 220 correctly when default route is
changed or does it correct not every time.
My scheme is:
rw-psk(virtual ip)ipsec-gw---subnet1 and subnet2
rw-psk ipsec.conf:
conn wasp-psk
left=%any
leftsourceip=%cfg
leftid=@warm
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: [
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(UPDA
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 NA
Dear list:
Our customer running StrongSwan 4.6.1 want to setup two external interfaces in
their VPN gateway, one for cellular and one for wi-fi.
They reported that the road warriors can only switch once. Subsequent attempts
to switch back to the initially connected interface won't work.
We fi
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
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.
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.
>>
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 t
> 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 i
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
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 traff
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
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@list
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
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
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
>
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 IP
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/implem
Greetings!
I've been using strongSwan 4.3.0 and I cannot figure out how to configure it in
order to achieve Mobility Scenario from RFC 4621 (page 6), more precisely
break-before-make case. Make-before-break is working fine. My ipsec.conf file
looks like this:
config setup
plutostart=no
conn
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
Hi all,
I have a problem. I have been training to use MobIKE in order to simulate a
mobile scenario: I create two wireless net with two SSID (net A amd net B),
the Initiator has only one wireless interface (ath0) and moves to net A from
net B. In order to send a HTTP request to YouTube.com server
Hi, all
Section 5.2.3 of RFC4621says
We do not want to do unnecessary UDP encapsulation unless there is
really a NAT between peers, i.e.,
UDP encapsulation should only be enabled when we actually detect NAT.
This behavior makes sense. Actually, in real world, extra-UDP-enc
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
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. Herb
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
discuss
: 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
uthby=secret
auto=add
-Original Message-
From: users-boun...@lists.strongswan.org
[mailto:users-boun...@lists.strongswan.org] On Behalf Of Adam French
Sent: Friday, December 12, 2008 4:45 PM
To: users@lists.strongswan.org
Subject: [strongSwan] Mobike problem and route table 220
Hi,
I
Hi,
I have been testing mobike switching with Strongswan 4.2.9 release. The
test uses a similar configuration as the mobike test #113. My test is
slightly different, in that both of alices interface (eth1 and eth0) are
behind gateways. The problem I have nocticed is that client alice does
not upd
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,
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 e
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 IP
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 correspo
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 t
48 matches
Mail list logo
