3

I'm on a ArchLinux-System trying to connect to my company VPN, which is served by a Juniper SRX100H. I'm trying to connect with Strongswan (5.5.3-3), and it seems to be successful:

Starting strongSwan 5.5.3 IPsec [starter]...
generating QUICK_MODE request 2638887156 [ HASH SA No KE ID ID ]
sending packet: from 192.168.1.204[4500] to 10.0.0.1[4500] (396 bytes)
received packet: from 10.0.0.1[4500] to 192.168.1.204[4500] (364 bytes)
parsed QUICK_MODE response 2638887156 [ HASH SA No KE ID ID ]
CHILD_SA test{2} established with SPIs cad5681f_i 4015b7bd_o and TS 192.168.1.204/32 === 192.168.32.0/24
connection 'test' established successfully

The problem is, that after that i can't ping anything but 10.0.0.1, which returns a response. But i can't reach any of the peers inside 192.168.32.0/24.

My ipsec.conf looks like:

conn test
    left=%any
    leftid=test@SRX100-local.de
    leftauth=psk
    leftauth2=xauth
    rightsubnet=192.168.32.0/24
    rightid=10.0.0.1
    rightauth=psk
    auto=start
    xauth_identity=USER
    esp=aes256-sha1-modp1536
    ike=aes256-sha2_256-modp1536
    aggressive=yes
    type=tunnel

The output of ip route show is:

default via 192.168.1.1 dev wlp3s0 proto static metric 600 
192.168.1.0/24 dev wlp3s0 proto kernel scope link src 192.168.1.204 metric 600

Other Clients (Windows) can connect with NCP Secure Client, so i guess it's not a firewall issue on the Juniper-side.

Any help would be appreciated :)

Update

Output of iptables-save

# Generated by iptables-save v1.6.1 on Tue Aug  8 11:24:43 2017
*filter
:INPUT ACCEPT [5:2010]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [7:999]
-A INPUT -s 192.168.32.0/24 -d 192.168.1.204/32 -i wlp3s0 -m policy --dir in --pol ipsec --reqid 1 --proto esp -j ACCEPT
-A OUTPUT -s 192.168.1.204/32 -d 192.168.32.0/24 -o wlp3s0 -m policy --dir out --pol ipsec --reqid 1 --proto esp -j ACCEPT
COMMIT
# Completed on Tue Aug  8 11:24:43 2017

The charon_debug.log is here: https://pastebin.com/jYiqpLip

Sentenza
  • 101
  • 1
  • 1
  • 8
  • Could be a routing problem. Is the remote peer the default gateway of the 192.168.32.0/24 subnet? If not, do the hosts there know they have to send packets to 192.168.1.204 via that gateway? Try finding out where exactly the packets are dropped (i.e. do they reach the remote subnet/host, is there a response?) – ecdsa Jul 24 '17 at 12:09
  • @ecdsa: Thanks for your response. The remote peer is the default gateway. Remote hosts do have access to the Internet. Traceroute did not output something useful (just ***). Is there another tracing tool, that could work in that context? – Sentenza Jul 24 '17 at 12:31
  • If you have access to any of the remote hosts you could use tcpdump/Wireshark to see if the packets arrive and a response is sent. Perhaps there is some firewalling going on on the Juniper box. Also, did you try what happens if you configure `leftsourceip=%config`? – ecdsa Jul 28 '17 at 08:57
  • @ecdsa Other Clients (Windows) can connect with NCP Secure Client, so i guess it's not a firewall issue on the Juniper-side. Setting `leftsourceip=%config` unfortunately did not work, too... – Sentenza Jul 28 '17 at 09:17

3 Answers3

2

As helped by @ecdsa via IRC:

The missing properties were leftsourceip=%config and modeconfig=push, because the Juniper is pushing the required settings to the client.

Sentenza
  • 101
  • 1
  • 1
  • 8
0

This was the solution for me to ssh to any host in the network on the other side of the tunnel.

Allow IPv4 forwarding

Edit /etc/sysctl.conf to allow forwarding in the Linux kernel.

vi /etc/sysctl.conf

Add the following line into the file.

net.ipv4.ip_forward=1

Save the file, then apply the change.

sysctl -p
zarvox
  • 111
  • 1
  • 1
  • 5
  • thanks for your reply, sadly I still can't ping with this setting... :( – Sentenza Jul 28 '17 at 15:52
  • I had the same problem before, the tunnel was up and running but I could not get any traffic through. On linux I use iptables to forward the traffic through the tunnel. leftfirewall=yes together with net.ipv4.ip_forward=1 should do the trick and I am quite sure you should look in that direction. Post your result from iptables -L – zarvox Jul 28 '17 at 16:21
  • thanks, I postet iptables -L and tried it with `leftfirewall=yes` together, but still doesn't work... – Sentenza Jul 28 '17 at 22:43
  • add accept rules for udp port 500 and 4500, start iptables and restart strongswan tunnel. leftfirewall=yes should add ACCEPT all -- 10.0.0.0/24 10.10.0.0/24 policy match dir in pol ipsec reqid 1 proto esp ACCEPT all -- 10.10.0.0/24 10.0.0.0/24 policy match dir out pol ipsec reqid 1 proto esp (these are my tunnnel networks connected) – zarvox Jul 29 '17 at 00:01
  • I stopped iptables on my machine and tried it, didn't work, so is iptables really the issue here? – Sentenza Aug 03 '17 at 16:09
  • You need two things: A working tunnel and some mechanism to force the traffic in the right direction. For that you need iptables, the ip_forward setting and a route table. Check this: https://www.strongswan.org/testresults.html . In these tests you can see the (iptables) settings on both side of the tunnel and compare it with yours! – zarvox Aug 04 '17 at 12:51
  • ip tables should something like this (but this is only for 1 side of the tunnel): https://www.strongswan.org/testing/testresults/ikev2/acert-cached/carol.iptables-save – zarvox Aug 04 '17 at 13:00
  • Ok, I started iptables and `leftfirewall=yes` did change it's settings. I postet `iptables-save` above, but it still does not work. It also is not the same as in your link, but I don't understand why and what I need to do in order to get this working... – Sentenza Aug 08 '17 at 09:35
  • Thanks so much for your help. Iptables was not the problem though, please see my answer :) – Sentenza Aug 08 '17 at 14:09
  • Glad to hear you solved it. Are you running without iptables now? – zarvox Aug 08 '17 at 15:06
  • Yes, it is working with and without iptables – Sentenza Aug 08 '17 at 15:37
-1

I guess this has to do with iptables

try to add this:

leftfirewall=yes
rightfirewall=yes
zarvox
  • 111
  • 1
  • 1
  • 5
  • `rightfirewall` does not really exist, you can't set any firewall rules on the remote host. – ecdsa Jul 24 '17 at 12:10
  • Thanks for your answers. Unfortunately it did not work. Other Windows Clients can connect with NCP Secure Client, so i guess it's not a firewall issue. – Sentenza Jul 24 '17 at 12:21
  • rightfirewall does not really exist? https://wiki.strongswan.org/projects/strongswan/wiki/ConnSection (left|rightfirewall = yes | no) – zarvox Jul 24 '17 at 12:40
  • @zarvox It's accepted in the config but it has no effect. The only exception to that is if the config gets switched (i.e `right*` options are applied locally, which could happen if the host/address in `right` is found to be local). – ecdsa Jul 24 '17 at 13:25
  • @ ecdsa, I understand the point. you can't change remote firewall settings... thanx! – zarvox Jul 24 '17 at 13:36