Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

From RHEL i have to connect VPN server and reach that target PC1. Till now it was possible to make the VPN interconnect but 10.0.0.108 cant ping 10.109.0.200.

Variables:

ME WAN IP: 8.8.8.8 (Amazon Elastic IP)
              ^\__ ME LAN IP: 10.0.0.108 (Amazon VPC)

VPN Server: 9.9.9.9 (Public Internet)
              ^\__ Behind VPN Target PC1: 10.109.0.200



$ service ipsec restart; ipsec auto --add test; ipsec auto --up test
ipsec_setup: Stopping Openswan IPsec...
ipsec_setup: Starting Openswan IPsec U2.6.32/K2.6.32-358.el6.x86_64...
ipsec_setup: multiple ip addresses, using  10.0.0.108 on eth0
ipsec_setup: /usr/libexec/ipsec/addconn Non-fips mode set in /proc/sys/crypto/fips_enabled
ipsec_setup: defaulting leftsubnet to 8.8.8.8
/usr/libexec/ipsec/addconn Non-fips mode set in /proc/sys/crypto/fips_enabled
defaulting leftsubnet to 8.8.8.8
104 "test" #1: STATE_MAIN_I1: initiate
003 "test" #1: ignoring unknown Vendor ID payload [8f9cc94e01248ecdf147594c284b213b]
003 "test" #1: ignoring Vendor ID payload [draft-stenberg-ipsec-nat-traversal-01]
003 "test" #1: ignoring Vendor ID payload [draft-stenberg-ipsec-nat-traversal-02]
003 "test" #1: ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-00]
003 "test" #1: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02] meth=107, but port floating is off
003 "test" #1: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02_n] meth=106, but port floating is off
003 "test" #1: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-03] meth=108, but port floating is off
003 "test" #1: received Vendor ID payload [RFC 3947] meth=109, but port floating is off
003 "test" #1: received Vendor ID payload [Dead Peer Detection]
106 "test" #1: STATE_MAIN_I2: sent MI2, expecting MR2
108 "test" #1: STATE_MAIN_I3: sent MI3, expecting MR3
004 "test" #1: STATE_MAIN_I4: ISAKMP SA established {auth=OAKLEY_PRESHARED_KEY cipher=aes_128 prf=oakley_md5 group=modp1024}
117 "test" #2: STATE_QUICK_I1: initiate
004 "test" #2: STATE_QUICK_I2: sent QI2, IPsec SA established tunnel mode {ESP/NAT=>0x071cca57 <0x88557c5e xfrm=AES_128-HMAC_MD5 NATOA=none NATD=none DPD=none}

$ ping 10.109.0.200
PING 10.109.0.200 (10.109.0.200) 56(84) bytes of data.
^
|______________ no reply for about 20 minutes like this 
share|improve this question

1 Answer 1

up vote 1 down vote accepted

The short answer is to look at your route table. Any tunnel-based VPN will add a new virtual interface of some sort, and routes. See if your default gateway changes. See if any static routes get added for specific networks.

Run a traceroute tool of your choice (eg mtr hostname), which shows you the path a series of packets followed to reach a particular destination.

share|improve this answer
    
Working now: unix.stackexchange.com/a/85133/11085 –  YumYumYum Aug 1 '13 at 1:47

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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