| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <606676310909020741n70d46b3ev1197b487feaedb19@mail.gmail.com>
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