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[4500] to[4500] (396 bytes)
received packet: from[4500] to[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 ===
connection 'test' established successfully

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

My ipsec.conf looks like:

conn test

The output of ip route show is:

default via dev wlp3s0 proto static metric 600 dev wlp3s0 proto kernel scope link src 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 :)


Output of iptables-save

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

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

  • Could be a routing problem. Is the remote peer the default gateway of the subnet? If not, do the hosts there know they have to send packets to 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


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.


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.


Save the file, then apply the change.

sysctl -p
  • 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 -- policy match dir in pol ipsec reqid 1 proto esp ACCEPT all -- 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

I guess this has to do with iptables

try to add this:

  • 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.