Parece que as regras da tabela de entrada do iptables não permitem pacotes ESP. Você pode tentar adicionar "iptables -A INPUT -pesp -j ACCEPT" ao iptables.
Eu tenho um Centos 6.6 VPS na Internet que tem um IP público. Instalei o StrongSwan 5.1.3 para permitir que meu telefone BlackBerry10 se conecte a partir de pontos de acesso e use a conexão do VPS. O IP do VPS mostra quando eu vou para www.whatismyip.com, e então eu acho que essa parte está funcionando bem.
Gostaria agora de fazer algum desenvolvimento / teste onde, quando o telefone estiver ligado ao VPS, gostaria que o VPS pudesse aceder ao telefone usando o IP que lhe foi atribuído pela Strongswan. (ou seja, ping 192.168.179.101, https para 192.168.179.101) No entanto, eu não acho que o Centos saiba como obter o tráfego para esse cliente específico. O que muda para StrongSwan e / ou iptables seria necessário para permitir que isso acontecesse?
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
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
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
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 -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
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
Quais mudanças no StrongSwan e / ou iptables seriam necessárias para permitir que eu acesse o cliente pelo IP do próprio servidor StrongSwan?
Muito obrigado antecipadamente !!!
Parece que as regras da tabela de entrada do iptables não permitem pacotes ESP. Você pode tentar adicionar "iptables -A INPUT -pesp -j ACCEPT" ao iptables.
Tags vpn iptables route strongswan