[Openswan Users] Established Tunnel Not Passing Traffic

[Neal Murphy]

On Thursday, June 27, 2013 07:04:15 PM Dave Ariens wrote:
> Could me trying to ping the other end have allowed the ESP protocol / UDP
> packets in somehow?

No, but allowing ESP/500/4500 *out* might've enabled the IPSEC netfilter 
helper to allow certain things in (if NAT exists anywhere). That is, if one 
end can get out on the correct ports/protos and the other lets them in, 
there's a good chance things would just work. It's hard to tell without seeing 
your network config(s) in minute detail (Where is NAT and any inbound 
forwards? What's allowed out? What's allowed in? Are there other related 
filters? What is routed where?

> 
> On Thu, Jun 27, 2013 at 5:24 PM, Dave Ariens <dave at ariens.ca> wrote:
> > I checked my iptables on the two end points and I only had:
> > 
> > -A INPUT -s 216.58.86.104/32 -i eth0 -p esp -j ACCEPT
> > -A INPUT -s 216.58.86.104/32 -i eth0 -p udp -m udp --sport 500 --dport
> > 500 -j ACCEPT
> > -A INPUT -s 216.58.86.104/32 -i eth0 -p udp -m udp --sport 4500 --dport
> > 4500 -j ACCEPT
> > 
> > ...which was for the original tunnel that's been working fine not the one
> > between my two OpenSwan instances.
> > 
> > Adding the other end of the tunnel seems to have restored connectivity
> > across the tunnel, although I don't see any logs from Pluto after I made
> > the change.
> > 
> > How could the tunnel possibly have been established in the first place
> > without allowing esp/500/4500?
> > 
> > On Thu, Jun 27, 2013 at 3:46 PM, Neal Murphy 
<neal.p.murphy at alum.wpi.edu>wrote:
> >> It may be nothing, but why don't I see states QUICK_I1/R1/I2/R2?
> >> Possibly mismatched params between the two ends? (Unless you method
> >> doesn't use them.)