Project

General

Profile

Issue #472

Responder stops responding after two successful connections

Added by F DCG almost 7 years ago. Updated over 2 years ago.

Status:
Closed
Priority:
Normal
Category:
configuration
Affected version:
5.1.1
Resolution:
No feedback

Description

Hi,

After burning more than i care to remember on this topic i have decided to put my issue to the specialists .. ;-)
The issue concerns the following:
Two ubuntu boxes running SS 5.1.1, 1 client and 1 server (all x509 keys based)
Connection 1 is ok. (10.a.b.1 === 192.168.a.b --- 192.168.a.y === 10.a.b.254)
- Connection 2 is ok. (172.a.b.1 === 10.a.b.1 --- 10.a.b.254 === 172.a.b.254)
- Ping from 172.a.b.1 to 172.a.b.254 is ok as well
- Connection 3 from 172...1 to 172...254 is initiated from the client but NOTHING appears to be leaving the client/ is not picked up on the server side (loglevel 2 on cfg, dmn, ike, net, mgr, knl, lib)

Have a tail -f running on both the auth log as well as the syslog but both do not react. It indeed looks as if nothing is arriving at the server.
On the server side side there is just one physical nic and using ip addres add ... i have added the additional required nics via the label ethX:Y construct. On the client side i am creating virtual IPs, which work just fine when pinging. Leaving the first two connections running shows me that all is ok in that area.

Is there any reason why i cannot add the 3rd connection? For it seems thet the non-response is caused by packets not leaving the client when the request is issued. At least, using wireshark i cannot see anything arriving (whilst pings do arrive). I'm assuming the basic settings are ok, for the 1st two connections work just fine.

I have not added any files and output yet because they are spread across machines and maybe there is a clear and simple answer without adding all the paperwork .. ;-)

Tia & reg.

Fermin DCG

cli-ipsec.conf (1.68 KB) cli-ipsec.conf F DCG, 29.12.2013 13:08
cli-strongswan.conf (569 Bytes) cli-strongswan.conf F DCG, 29.12.2013 13:08
svr-ipsec.conf (1.11 KB) svr-ipsec.conf F DCG, 29.12.2013 13:08
svr-strongswan.conf (569 Bytes) svr-strongswan.conf F DCG, 29.12.2013 13:08
clientLogs (69.2 KB) clientLogs The auth and syslog info of the client F DCG, 29.12.2013 13:08
serverLogs (46.8 KB) serverLogs The auth and syslog info of the server F DCG, 29.12.2013 13:08

Related issues

Related to Issue #542: Nesting tunnelsFeedback06.03.2014

History

#1 Updated by F DCG almost 7 years ago

Update.

Since the clients are not supposed to go to the internet (the server should have a conection due to clients logging in) i decided to change the l/r subnets to 0.0.0.0/0. This solved the problem of the signal not coming through.
At this moment the client initiates the request to connect which (according to the logs and wireshark) is replied upon by the server by sending out a cert request. Based on the fact that the 1st requests were ok i would expect the 3rd request to react in the same manner.

The listcerts commands comes back as expected.
The client conf is just a tad different. The first two connections conn01 and conn02 are still fine but the they are flipped compared to my first comment.
Re. the cert used. Tried with a different one and one that already worked on the first connection.

Attached the conf files and the corresponding logs. They show the 3rd requerst being made, a reply produced and nothing arriving on the client.

Really hope someone can shed some light on this ..
Tia again,

Fermin DCG

#2 Updated by Tobias Brunner almost 7 years ago

  • Status changed from New to Feedback
  • Assignee set to Tobias Brunner

Hm, what exactly are you trying to accomplish with those nested tunnels? (In general nested IPsec tunnels initiated from the same host are not supported).

Then your config is not correct, leftsourceip on the client without configuring rightsourceip on the server has no effect (see VirtualIP for details). If you configure the virtual IPs yourself (i.e. no negotiation of the IP is required) just configure the IP as leftsubnet on the client.

The log message seen on the client regarding the leftsourceip option

Dec 29 12:56:03 vblubu14-32b charon: 05[CFG] ignored invalid subnet token: 172.22.0.1

is actually incorrect (but it's not really a problem as it's just that the message is printed when it shouldn't, fixed with 261fd9d33).

#3 Updated by F DCG over 6 years ago

Tobias Brunner wrote:

Hm, what exactly are you trying to accomplish with those nested tunnels? (In general nested IPsec tunnels initiated from the same host are not supported).

Sorry this is a late reaction but i'v been at this for quite a bit.
Thank you for your reply. There were some bits in there that helped me but not all is fine, yet.
Re. your (expected) question, the following:
- Does it really matter ;-) .. Nonetheless, with all this stuff going on i figured nesting tunnels would at least make it a factor more difficult to get to the payload. I'm not paying taxes for some gov willies' salary to have him muck around with my data .. He should go and catch criminals etc. (imho)
- And, seeing the elegance of the whole strongswan package i thought this should be workable

Then your config is not correct, leftsourceip on the client without configuring rightsourceip on the server has no effect (see VirtualIP for details). If you configure the virtual IPs yourself (i.e. no negotiation of the IP is required) just configure the IP as leftsubnet on the client.

Changed the conf as per your suggestion and i'v got it stacking >2 layers now. Every new layer uses the IPs of the latest tunnel.
So, tunnel 1 (the very 1st one) uses the normal client and server IPs. Works fine (also in a WAN setting).
Now tunnel 2 uses the virt-IP on the client and the alias-IP (created via ip link add, iproute2) for initialization. Finishes successfully, by the looks of it. (but only in a LAN, not a WAN)
By manually adding some additional routing info i can now also do the same when initializing the 3rd tunnel. However, i does smell like a bit of witchcraft.

Now, here is my issue. When issuing a ping from the highest client tunnel IF to the corresponding tunnel IF on the server i would expect the traffic to move down and up through the layers, exiting on the server side. Traffic does arrive there because the service running is only listening on the outer IF-address. I do not, however, know whether the route taken was the correct one and the encryption used equals the encryption planned.
Should this at all be possible or rather, can strongswan be used to nest tunnels (for whatever reason ;-))?
If so, would the above route be the correct one? If not, how would one go about it?
And, how can one be certain that tunnels are nested. Ie. how to verify the multi-layered encryption ..

server conn entries: left is server itself
---
left=[address as defined via ip link add]
leftfirewall=yes
right=%any
rightsourceip=%config

client conn entries: left is client itself
---
left=[previous tunnel ip address]
leftsourceip=[the new virtual(tunnel) ip, differs per client]
right=[server ip]
rightsubnet=0.0.0.0/0

All the connections are created but i cannot follow the traffic in wireshark, am seeing non-esp ping packets.

Tia for the effort and your time

Fermin DCG

#4 Updated by Tobias Brunner over 6 years ago

#5 Updated by Tobias Brunner over 2 years ago

  • Status changed from Feedback to Closed
  • Resolution set to No feedback

Closing old issues. If this is still a problem, please reopen.

Also available in: Atom PDF