Date:	Wed, 2 Sep 2009 07:41:04 -0700
From:	Andrew Dickinson <andrew@...dna.net>
To:	netdev@...r.kernel.org
Subject: Re: ipsec not forwarding (suspect SA issue)

Just to follow up on this... it was an SA issue, but due to my config
and not a kernel problem. :D

specifically, I changed the "uniques" to "requires" in the spdadd
lines and dropped the "fwd" entry that I'd manually added... that
straightened everything out :D

-A

On Tue, Sep 1, 2009 at 11:57 AM, Andrew Dickinson<andrew@...dna.net> wrote:
> Howdy netdev,
>
> First, I'm not positive that this is the right list for this question,
> so feel free to steer me in the right direction.  I'm trying to work
> out an issue with ipsec not forwarding traffic from my LAN down my
> tunnel.  I've walked through the troubleshooting-doc on the lartc site
> and everything seems kosher...
>
> Here's my setup.
>
> I've got a linux-based router/firewall on the edge of my network with
> two interfaces, $WAN and $LAN.  The router is MASQUERADING to the
> internet.  My LAN is 10.0.0.0/24.  I'm trying to peer with a remote
> network 10.254.0.0/23.  The remote network does not have internet
> connectivity, so all non-10.254/23 traffic should traverse the VPN to
> get to my router to go to the internet or my local LAN.
>
> I'm using racoon and setkey to establish the VPN tunnel and BGP (via
> quagga) to advertise routes into the remote network.  The routers are
> using 169.254.255.0/30 for BGP.
>
> The problem that I'm having is that traffic from my LAN to 10.254/23
> is not going down the VPN tunnel; it just disappears.  I can see it
> come in on the LAN interface, but I don't see it leave the WAN
> interface as either unencrypted traffic or as esp traffic.  Traffic
> from the router, however, works fine.
>
> ------ BEGIN racoon.conf ------
> log info;
>
> path pre_shared_key "/etc/racoon/psk.txt";
>
>
> listen {
>    adminsock "/var/run/racoon/racoon.sock" "root" "operator" 0660;
>    isakmp <MY_IP>
> }
>
> timer {
>    counter 5;
>    interval 20 sec;
>    persend 1;
>    phase1 30 sec;
>    phase2 15 sec;
> }
>
> remote anonymous {
>    exchange_mode main,aggressive,base;
>    lifetime time 28800 sec;
>    proposal_check obey;
>    dpd_delay 10;
>    dpd_retry 10;
>    dpd_maxfail 3;
>    esp_frag 1396;
>    proposal {
>        encryption_algorithm aes;
>        hash_algorithm sha1;
>        authentication_method pre_shared_key;
>        dh_group 2;
>    }
> }
>
> sainfo anonymous {
>    authentication_algorithm hmac_sha1;
>    encryption_algorithm aes;
>    lifetime time 3600 seconds;
>    compression_algorithm deflate;
>    pfs_group 2;
> }
>
> ------- END racoon.conf -------
>
> ------ BEGIN setkey.conf -----
> flush;
> spdflush;
>
>
> spdadd 169.254.255.1 169.254.255.2 any -P in ipsec
>    esp/tunnel/REMOTE_IP-MY_IP/unique;
> spdadd 169.254.255.2 169.254.255.1 any -P out ipsec
>    esp/tunnel/MY_IP-REMOTE_IP/unique;
>
> spdadd 10.254.0.0/23 0.0.0.0/0 any -P in ipsec
>    esp/tunnel/REMOTE_IP-MY_IP/unique;
> spdadd 0.0.0.0/0 10.254.0.0/23 any -P fwd ipsec
>    esp/tunnel/MY_IP-REMOTE_IP/unique;
> spdadd 0.0.0.0/0 10.254.0.0/23 any -P out ipsec
>    esp/tunnel/MY_IP-REMOTE_IP/unique;
>
> spdadd 0.0.0.0/0 0.0.0.0/0 254 -P in ipsec
>    esp/tunnel/REMOTE_IP-MY_IP/unique;
> spdadd 0.0.0.0/0 0.0.0.0/0 254 -P out ipsec
>    esp/tunnel/MY_IP-REMOTE_IP/unique;
>
> spdadd 0.0.0.0/0 0.0.0.0/0 tcp -P in none;
> spdadd 0.0.0.0/0 0.0.0.0/0 tcp -P out none;
> spdadd 0.0.0.0/0 0.0.0.0/0 udp -P in none;
> spdadd 0.0.0.0/0 0.0.0.0/0 udp -P out none;
>
> ----- END setkey.conf ----
>
> There's two things that are potentially funky with this config that
> I'm not proud of (and which might potentially be part of my problem).
> When racoon goes to phase2 negotiation, it looks for an SPD with 0/0 -
> 0/0 [any] .   I've installed an SPD of 0/0 - 0/0 [254] in order to
> make racoon happy.  This isn't a problem for me as I don't have any
> traffic using IP protocol #254 (obviously).  The other thing is that
> I'm explicitly adding a fwd rule... that was my effort to try to fix
> my problem (it didn't help).  Beyond that, the rest of the rules seem
> fairly straight forward.
>
> Further, when I initially connect the VPN, I see racoon do an SA
> negotiation for the 0/0 rules.  When I start quagga, I see it do an SA
> for the 169.254... rules.  If I ping a remote machine from the
> routers, I see it do an SA for the 10.254.0.0/23 rules.  But if I ping
> from something on my LAN there's no negotiation (this is true whether
> I ping from the router first or not).
>
> Here's what I've double checked:
> 1) iptables nat table has rules to ACCEPT 10.254.0.0/23 destined
> traffic to prevent it from being MASQUERADE'd (which I see counters
> for when I ping from the router)
> 2) iptables (main) table has FORWARD rules to ACCEPT 10.254.0.0/23
> destined traffic (which I never see counters for)
> 3) IP forwarding is enabled (as this router is happily forwarding
> other traffic to-from the LAN to the internet)
>
> It seems like this is an issue with an SA not getting found for
> forwarding traffic and the kernel silently dropping the packet.  How
> do I debug this?
>
> -A
>
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists