[Openswan Users] Can't ping peer after connection...

[Paul Wouters]

On Tue, 30 Dec 2008, Dan Brown wrote:

run ipsec barf on both ends and fix any potential warnings. check you're
not NAT'ing ipsec packets by accident.

Paul

> So yesterday we got our IPSec connection up for a little while after some
> troubleshooting.  A couple of hours later with no changes on either end the
> connection failed to renegotiate and could not properly reconnect.  During
> the period of a successful connection, I could ping the peer, but I couldn't
> connect to the server on the other side of the VPN gateway.  An nmap said
> the internal server was down (regardless of port).  
> 
> We were thinking the problem may have been with the firewalling on the
> internal server.  Now I am not so sure.  
> 
> If I start a ping, then bring up the connection, the responses stop.  I
> could never ping or see an open port on the internal server so perhaps two
> one-sided tunnels were actually created from the other side.
> 
> This is what ipsec whack --status shows for this connection:
> 
> 000 "g2c-p":
> 209.167.162.84/32===209.167.162.84...207.236.235.99===199.43.146.0/24;
> erouted; eroute owner: #3
> 000 "g2c-p":     srcip=unset; dstip=unset; srcup=ipsec _updown; dstup=ipsec
> _updown;
> 000 "g2c-p":   ike_life: 3600s; ipsec_life: 28800s; rekey_margin: 540s;
> rekey_fuzz: 100%; keyingtries: 0
> 000 "g2c-p":   policy: PSK+ENCRYPT+TUNNEL+PFS+UP; prio: 32,24; interface:
> eth0; encap: esp;
> 000 "g2c-p":   newest ISAKMP SA: #1; newest IPsec SA: #3; 
> 000 "g2c-p":   IKE algorithms wanted: 3DES_CBC(5)_000-SHA1(2)-MODP1536(5),
> 3DES_CBC(5)_000-SHA1(2)-MODP1024(2); flags=strict
> 000 "g2c-p":   IKE algorithms found:
> 3DES_CBC(5)_192-SHA1(2)_002-MODP1536(5),
> 3DES_CBC(5)_192-SHA1(2)_002-MODP1024(2)
> 000 "g2c-p":   IKE algorithm newest: 3DES_CBC_192-SHA1-MODP1024
> 000 "g2c-p":   ESP algorithms wanted: AES(12)_128-SHA1(2),
> 3DES(3)_000-SHA1(2); flags=strict
> 000 "g2c-p":   ESP algorithms loaded: AES(12)_128-SHA1(2),
> 3DES(3)_000-SHA1(2); flags=strict
> 000 "g2c-p":   ESP algorithm newest: 3DES_0-HMAC_SHA1; pfsgroup=<Phase1>
> 000  
> 000 #3: "g2c-p":500 STATE_QUICK_I2 (sent QI2, IPsec SA established);
> EVENT_SA_REPLACE in 27211s; newest IPSEC; eroute owner
> 000 #3: "g2c-p" esp.79e8e525 at 207.236.235.99 esp.e6dcb67b at 209.167.162.84
> tun.0 at 207.236.235.99 tun.0 at 209.167.162.84
> 000 #2: "g2c-p":500 STATE_QUICK_I2 (sent QI2, IPsec SA established);
> EVENT_SA_REPLACE in 26516s
> 000 #2: "g2c-p" esp.8bbfd32c at 207.236.235.99 esp.f5f4af97 at 209.167.162.84
> tun.0 at 207.236.235.99 tun.0 at 209.167.162.84
> 000 #1: "g2c-p":500 STATE_MAIN_I4 (ISAKMP SA established); EVENT_SA_REPLACE
> in 1229s; newest ISAKMP; lastdpd=2s(seq in:0 out:0)
> 000  
> 
> 
> To me this looks like two one sided connections.  Should I be able to ping
> the peer after the tunnel starts?
> 
> ---------------
> Dan Brown
> danb at zu.com
> 
> 
> 
> _______________________________________________
> Users at openswan.org
> http://lists.openswan.org/mailman/listinfo/users
> Building and Integrating Virtual Private Networks with Openswan: 
> http://www.amazon.com/gp/product/1904811256/104-3099591-2946327?n=283155
>