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

Improve this question
4
  • 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, 2017 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, 2017 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, 2017 at 8: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, 2017 at 9:17

3 Answers 3

Reset to default
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.

Improve this answer
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
Improve this answer
11
  • thanks for your reply, sadly I still can't ping with this setting... :(
    – Sentenza
    Jul 28, 2017 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, 2017 at 16:21
  • thanks, I postet iptables -L and tried it with leftfirewall=yes together, but still doesn't work...
    – Sentenza
    Jul 28, 2017 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, 2017 at 0:01
  • I stopped iptables on my machine and tried it, didn't work, so is iptables really the issue here?
    – Sentenza
    Aug 3, 2017 at 16:09
-1

I guess this has to do with iptables

try to add this:

leftfirewall=yes
rightfirewall=yes
Improve this answer
5
  • rightfirewall does not really exist, you can't set any firewall rules on the remote host.
    – ecdsa
    Jul 24, 2017 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, 2017 at 12:21
  • rightfirewall does not really exist? wiki.strongswan.org/projects/strongswan/wiki/ConnSection (left|rightfirewall = yes | no)
    – zarvox
    Jul 24, 2017 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, 2017 at 13:25
  • @ ecdsa, I understand the point. you can't change remote firewall settings... thanx!
    – zarvox
    Jul 24, 2017 at 13:36

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.