3

I have a Centos 6.6 VPS out on the Internet that has a public IP. I have installed StrongSwan 5.1.3 to allow my BlackBerry10 phone to connect from hotspots and use the VPS' connection. The VPS' IP shows when I go to www.whatismyip.com, and so I think that part is working well.

I would now like to do some development/testing where when the phone is connected to the VPS, I would like for the VPS to be able to access the phone using the IP it was assigned by Strongswan. (ie, ping 192.168.179.101, https to 192.168.179.101) However, I don't think that Centos knows how to get the traffic to that specific client. What changes to StrongSwan and/or iptables would be needed to allow this to happen?

Here is my ipsec.conf:

config setup
strictcrlpolicy=no

conn %default
ikelifetime=24h
keylife=24h
keyexchange=ikev2
dpdaction=clear
dpdtimeout=3600s
dpddelay=3600s
compress=yes

conn rem
rekey=no
leftsubnet=0.0.0.0/0
leftauth=psk
leftid=162.244.xxx.xxx
right=%any
rightsourceip=192.168.179.100/29
rightauth=eap-mschapv2
rightsendcert=never
eap_identity=%any
auto=add

iptables -L

Chain INPUT (policy ACCEPT)
target     prot opt source               destination
fail2ban-SSH  tcp  --  anywhere             anywhere            tcp dpt:ssh
ACCEPT     tcp  --  anywhere             anywhere            multiport dports http,https
fail2ban-SSH  tcp  --  anywhere             anywhere            tcp dpt:ssh
ACCEPT     udp  --  anywhere             anywhere            udp dpt:l2tp
ACCEPT     udp  --  anywhere             anywhere            udp dpt:ipsec-nat-t
ACCEPT     udp  --  anywhere             anywhere            udp dpt:isakmp

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination
TCPMSS     tcp  --  anywhere             anywhere            tcp flags:SYN,RST/SYN TCPMSS clamp to PMTU

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

Chain fail2ban-SSH (2 references)
target     prot opt source               destination
REJECT     all  --  static-108-35-57-14.nwrknj.fios.verizon.net  anywhere            reject-with icmp-port-unreachable
RETURN     all  --  anywhere             anywhere
RETURN     all  --  anywhere             anywhere

ip xfrm policy

src 192.168.179.101/32 dst 0.0.0.0/0
        dir fwd priority 1923 ptype main
        tmpl src 207.81.yy.x dst 162.244.xx.yy
                proto esp reqid 1 mode tunnel
src 192.168.179.101/32 dst 0.0.0.0/0
        dir in priority 1923 ptype main
        tmpl src 207.81.yy.x dst 162.244.xx.yy
                proto esp reqid 1 mode tunnel
src 0.0.0.0/0 dst 192.168.179.101/32
        dir out priority 1923 ptype main
        tmpl src 162.244.xx.yy dst 207.81.yy.x
                proto esp reqid 1 mode tunnel
src 0.0.0.0/0 dst 0.0.0.0/0
        dir 3 priority 0 ptype main
src 0.0.0.0/0 dst 0.0.0.0/0
        dir 4 priority 0 ptype main
src 0.0.0.0/0 dst 0.0.0.0/0
        dir 3 priority 0 ptype main
src 0.0.0.0/0 dst 0.0.0.0/0
        dir 4 priority 0 ptype main
src ::/0 dst ::/0
        dir 3 priority 0 ptype main
src ::/0 dst ::/0
        dir 4 priority 0 ptype main
src ::/0 dst ::/0
        dir 3 priority 0 ptype main
src ::/0 dst ::/0
        dir 4 priority 0 ptype main

ipsec statusall

Status of IKE charon daemon (strongSwan 5.1.3, Linux 2.6.32-504.el6.x86_64, x86_64):
  uptime: 19 minutes, since Nov 11 18:58:51 2014
  malloc: sbrk 503808, mmap 0, used 398608, free 105200
  worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0, scheduled: 1
  loaded plugins: charon curl ldap pkcs11 aes des rc2 sha1 sha2 md4 md5 random nonce x509 revocation constraints pubkey pkcs1 pkcs7 pkcs8 pkcs12 pgp dnskey sshkey pem openssl fips-prf gmp xcbc cmac hmac ccm gcm attr kernel-netlink resolve socket-default farp stroke updown eap-identity eap-aka eap-aka-3gpp2 eap-md5 eap-gtc eap-mschapv2 eap-dynamic eap-radius eap-tls eap-ttls eap-peap eap-tnc xauth-generic xauth-eap tnc-tnccs dhcp
Virtual IP pools (size/online/offline):
  192.168.179.100/29: 6/1/0
Listening IP addresses:
  162.244.xx.yy
Connections:
         rem:  %any...%any  IKEv2, dpddelay=3600s
         rem:   local:  [162.244.xx.yy] uses pre-shared key authentication
         rem:   remote: uses EAP_MSCHAPV2 authentication with EAP identity '%any'
         rem:   child:  0.0.0.0/0 === dynamic TUNNEL, dpdaction=clear
Security Associations (1 up, 0 connecting):
         rem[1]: ESTABLISHED 19 minutes ago, 162.244.xx.yy[162.244.xx.yy]...207.81.yy.x[192.168.2.147]
         rem[1]: Remote EAP identity: Swan
         rem[1]: IKEv2 SPIs: 19996d366fee522a_i b35b5ed8c1720f74_r*, rekeying disabled
         rem[1]: IKE proposal: 3DES_CBC/HMAC_MD5_96/PRF_HMAC_MD5/MODP_1024
         rem{1}:  INSTALLED, TUNNEL, ESP in UDP SPIs: c75f570c_i 7a0f8418_o
         rem{1}:  AES_CBC_128/HMAC_SHA1_96, 123827 bytes_i (740 pkts, 3s ago), 358585 bytes_o (724 pkts, 3s ago), rekeying disabled
         rem{1}:   0.0.0.0/0 === 192.168.179.101/32

iptables rules (UDP ports 500, 4500 and 1701 shall be opened)

iptables -I POSTROUTING -t nat -o eth0 -j MASQUERADE
iptables -I FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
iptables -I INPUT -p udp --dport 500 -j ACCEPT
iptables -I INPUT -p udp --dport 4500 -j ACCEPT
iptables -I INPUT -p udp --dport 1701 -j ACCEPT

/etc/sysctl.conf

net.ipv4.ip_forward = 1
net.net.ipv4.conf.default.proxy_arp = 1
net.ipv4.conf.default.arp_accept = 1
net.ipv4.conf.default.proxy_arp_pvlan = 1
net.ipv4.conf.default.rp_filter = 1
net.ipv4.conf.default.accept_source_route = 0
kernel.sysrq = 0
kernel.core_uses_pid = 1
net.ipv4.tcp_syncookies = 1
kernel.msgmnb = 65536
kernel.msgmax = 65536
kernel.shmmax = 68719476736
kernel.shmall = 4294967296
net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1

What changes to StrongSwan and/or iptables would be needed to allow me to access the client by IP from the StrongSwan server itself?

Thanks very much in advance!!!

2
  • With your config you should already be able to access the client IP from your server. But perhaps there is a firewall running on the client that prevents inbound connections.
    – ecdsa
    Nov 13, 2014 at 10:04
  • I cannot be sure, but I'm expecting 443 to be open on the phone as its in development mode. I guess I need to capture some traffic and see if I can figure out what is happening. Not sure if I can just tcpdump eth0 or if I have to do something to see the tunnel traffic better. Time to tcpdump eth0 and see what I see.
    – Timbo
    Nov 14, 2014 at 4:19

1 Answer 1

2

It seems like the iptables input table rules do not allow ESP packets. You could try adding "iptables -A INPUT -p esp -j ACCEPT" to iptables.

1
  • 1
    The default policy for the chain is ACCEPT, so adding another ACCEPT rule to the end of the chain shouldn't change anything.
    – kasperd
    Jan 18, 2016 at 20:33

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .