Thread: [Ipsec-tools-users] roadwarrior behind NAT connecting racoon on router doing nat
Brought to you by:
mit_warlord,
netbsd
From: Götz Babin-E. <g.b...@no...> - 2012-01-18 09:09:38
Attachments:
PGP.sig
|
Hello, I have the following setup: roadwarrior <--> NAT router <--> IPSec server doing NAT <-> local host 10.10.10.128<->10.10.10.1/1.2.3.4 <--> eth0:1.2.3.5 eth1:192.168.1.1<->192.168.1.2 The IPSec server is using ipsec-tools 0.8.0. NAT is configured on the IPSec server with: iptables --table nat --append POSTROUTING --out-interface eth0 ! --protocol esp --jump MASQUERADE In this setup the roadwarrior can establish an IPSec connection to the server. With the open IPSec connection the roadwarrior can initialize connections to the local host. But opening connections from the local host to the roadwarrior is not possible, because somehow the IPSec server gets confused with the NAT setup and instead sends the packets with NAT but without IPSec to the out interface eth0 Inserting a iptables --table nat --insert 1 --out-interface eth0 --destination 10.10.10.0/24 --jump ACCEPT solves the problem. Unfortunately in the roadwarior case we normally don't have the IP address of the peer. Inserting the roadwarriors IP address in the phase-1 up script is not possible, because this information is not set from racoon on calling the script. Has anybody an idea how to solve this problem ? TIA Goetz |
From: Troy L. Y. <tyo...@ec...> - 2012-01-18 22:03:16
|
Götz: Looking at the diagram of your config, I see the following: RW Physical NIC IP (private): 10.10.10.128 RW Router IP (private): 10.10.10.1 RW Router IP (public): 1.2.3.4 VPN Server IP (public): 1.2.3.5 VPN Server IP (private): 192.168.1.1 Local Host IP (private): 192.168.1.2 What I don't see is the VPN Tunnel IP address that racoon hands out when RW initiates a connection inbound. How do your RW systems get an IP address from racoon? I'm using mode_cfg; when my RW systems connect, racoon assigns an IP address from a pool which doesn't cross any of my existing class C's. I also run split_network to specifically encrypt traffic targeted for addresses in my "private" class C. >From my configs: ---------------------------------------------------------- #racoon.conf listen { isakmp 1.2.3.5 [500]; isakmp-natt 1.2.3.5 [4500]; } remote anonymous { exchange_mode aggressive; # [ identifiers per your configurations ] passive on; generate_policy unique; ike_frag on; nat_traversal on; dpd_delay 15; initial_contact off; proposal_check claim; lifetime time 6 hours; proposal { # [ per your configurations ] } } mode_cfg { conf_source local; network4 10.10.11.1; < note different C subnet pool_size 254; netmask4 255.255.255.0; split_network include 192.168.1.0/24; # [ other mode_cfg statements per your requirements ] } sainfo anonymous { # [ per your configurations ] } ---------------------------------------------------------- In "mode_cfg {network4/pool_size/netmask4}", I specify "10.10.11.0/24" as my VPN client address pool, and racoon hands those IP addresses out to my roadwarrior clients that connect to 1.2.3.5 (500 or 4500, depending on NAT-T requirements). According to "man racoon.conf", if "conf_source" is set to "local" or omitted, then the default values for network4, netmask4 & pool_size are: network4 0.0.0.0; netmask4 0.0.0.0; pool_size 255; If not using mode_cfg, I don't know how you'd assign a VPN tunnel IP address to your RW connections if you don't always know the source IP address your RW is at; I know you can use sainfo if your RWs always connect from specific IP addresses (but then you could just route back and not have these issues!). To route specific connections back to my roadwarriors, iptables has the following configurations: ---------------------------------------------------------- #iptables --list-rules --table mangle # sets a MARK on incoming esp packets on the external NIC for further routing -A PREROUTING -i $extif -p esp -j MARK --set-xmark 0x1/0xffffffff #iptables --list-rules --table nat # allows ESTABLISHED and RELATED packets through -A PREROUTING -m state --state RELATED,ESTABLISHED -j ACCEPT # allows routing of MARKed packets sourced from the VPN address range # on the external NIC (see "mangle" table); I guess you could use "-p esp" # as a filter as well -A PREROUTING -s 10.10.11.0/24 -i $extif -m mark --mark 0x1 -j ACCEPT # allows packets coming from the server directed out the internal NIC -A POSTROUTING -d 192.168.1.0/24 -o $intif -j ACCEPT # NOTE: My server is a stand-alone VPN concentrator with no routing # for outbound traffic from my private net; if you need this # functionality, you'll probably have to add a MASQUERADE target # jump somewhere in here, e.g. # -A POSTROUTING -s 192.168.1.0/24 -o $extif ! -p esp -j MASQUERADE # or # -A POSTROUTING ! -d 10.10.11.0/24 -o $extif -j MASQUERADE # I have NOT tested these, however; use at your own risk. #iptables --list-rules --table filter (aka iptables --list-rules) # all tables except OUTPUT default to DROP -P INPUT DROP -P FORWARD DROP -P OUTPUT ACCEPT # allows ESTABLISHED and RELATED packets inbound on any NIC -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT # allows all traffic inbound on the internal NIC -A INPUT -i $intif -j ACCEPT # allows loopback device traffic in or out -A INPUT -i lo -j ACCEPT -A INPUT -o lo -j ACCEPT # allows IPSEC traffic on the external NIC (accomodates both standard and NAT-T traffic) -A INPUT -i $extif -p esp -j ACCEPT -A INPUT -i $extif -p ah -j ACCEPT -A INPUT -i $extif -p udp -m multiport --dports 500,4500 -j ACCEPT # forwards traffic inbound on the internal NIC -A FORWARD -i $intif -j ACCEPT # forwards loopback device traffic in or out -A FORWARD -i lo -j ACCEPT -A FORWARD -o lo -j ACCEPT # forwards new inbound connections from the VPN address range (which shouldn't get here except via IPSec) -A FORWARD -s 10.10.11.0/24 -m state --state NEW -j ACCEPT # forwards new outbound connections from within the internal network address range that target # the VPN address range ::: THIS MAY BE WHAT YOU'RE MISSING ::: -A FORWARD -s 192.168.1.0/24 -d 10.10.11.0/24 -m state --state NEW -j ACCEPT # forwards any MARKed traffic (see "mangle" table) -A FORWARD -i $extif -m mark --mark 0x1 -j ACCEPT -A FORWARD -o $extif -m mark --mark 0x1 -j ACCEPT Without seeing your racoon.conf, it looks to me like you may be dealing with a routing issue (e.g. there's no route back to your roadwarrior clients in iptables)...and in order to route back to your RW clients, you're going to need to specify an address block in racoon.conf/mode_cfg to hand out to your RW clients via racoon so that iptables can establish a route. Or, I'm barking up the wrong tree (and I'm sure someone is going to let me know about that!). HTH, -- Troy -----Original Message----- From: Götz Babin-Ebell [mailto:g.b...@no...] Sent: Wednesday, January 18, 2012 12:53 AM To: ips...@li... Subject: [Ipsec-tools-users] roadwarrior behind NAT connecting racoon onrouter doing nat Hello, I have the following setup: roadwarrior <--> NAT router <--> IPSec server doing NAT <-> local host 10.10.10.128<->10.10.10.1/1.2.3.4 <--> eth0:1.2.3.5 eth1:192.168.1.1<->192.168.1.2 The IPSec server is using ipsec-tools 0.8.0. NAT is configured on the IPSec server with: iptables --table nat --append POSTROUTING --out-interface eth0 ! --protocol esp --jump MASQUERADE In this setup the roadwarrior can establish an IPSec connection to the server. With the open IPSec connection the roadwarrior can initialize connections to the local host. But opening connections from the local host to the roadwarrior is not possible, because somehow the IPSec server gets confused with the NAT setup and instead sends the packets with NAT but without IPSec to the out interface eth0 Inserting a iptables --table nat --insert 1 --out-interface eth0 --destination 10.10.10.0/24 --jump ACCEPT solves the problem. Unfortunately in the roadwarior case we normally don't have the IP address of the peer. Inserting the roadwarriors IP address in the phase-1 up script is not possible, because this information is not set from racoon on calling the script. Has anybody an idea how to solve this problem ? TIA Goetz |
From: Götz Babin-E. <g.b...@no...> - 2012-01-29 15:41:01
Attachments:
signature.asc
|
Am 18.01.2012 22:41, wrote Troy L. Yochelson: > Goetz: sorry for the delay... > > Looking at the diagram of your config, I see the following: > > RW Physical NIC IP (private): 10.10.10.128 > RW Router IP (private): 10.10.10.1 > RW Router IP (public): 1.2.3.4 > VPN Server IP (public): 1.2.3.5 > VPN Server IP (private): 192.168.1.1 > Local Host IP (private): 192.168.1.2 > > What I don't see is the VPN Tunnel IP address that racoon hands out when RW > initiates a connection inbound. > > How do your RW systems get an IP address from racoon? Is that mandatory ? Both ends use racoon 0.8.0, so there is no special tunnel device to assign an IP address to... Making an VPN tunnel address range mandatory just adds another thing that can break. Imagine choosing the 10.10.10.0/24 address range as tunnel address range... > Without seeing your racoon.conf, it looks to me like you may be dealing with > a routing issue (e.g. there's no route back to your roadwarrior clients in > iptables)...and in order to route back to your RW clients, you're going to > need to specify an address block in racoon.conf/mode_cfg to hand out to your > RW clients via racoon so that iptables can establish a route. It is not directly an routing issue, since iptables does not do routing. But issue is that iptables does not know that is must not do NAT for the RW private IP address. And that leads back to my initial complain: Why doesn't racoon tell anybody that it has there is a IP address that the system must send packets to via the IPSec tunnel? (and don't do NAT) Or if it can't, why does it not give the up script the chance to do that ? Goetz |
From: Troy L. Y. <tyo...@ec...> - 2012-01-30 20:20:41
|
Answering in-line. On 1/29/2012, Goetz Babin-Ebell wrote: >> Looking at the diagram of your config, I see the following: >> >> RW Physical NIC IP (private): 10.10.10.128 >> RW Router IP (private): 10.10.10.1 >> RW Router IP (public): 1.2.3.4 >> VPN Server IP (public): 1.2.3.5 >> VPN Server IP (private): 192.168.1.1 >> Local Host IP (private): 192.168.1.2 >> >> What I don't see is the VPN Tunnel IP address that racoon hands out when RW >> initiates a connection inbound. >> >> How do your RW systems get an IP address from racoon? > > Is that mandatory ? Well, I'm not the (or a) programmer...but it would seem to me that the answer to that question is "yes, it IS mandatory." However, that is what worked for me specifically (of course, my config is different; my VPN gateway is NOT my primary router, and I'm using mode_cfg to hand out specific IP addresses so that I can segregate my RW users from, say, my nailed-up VPN connections). So give this a shot: Your iptables statement that solves your problem for the 10.10.10.0/24 subnet specifically targets the 10.10.10.0/24 subnet. Try this: iptables --table nat --insert POSTROUTING 1 --out-interface eth0 --protocol esp --jump ACCEPT With this, you're explicitly targeting any "esp" packets headed for eth0 and specifying that they get through without NAT. Of course, that is going to de-NAT any "internal" connections to VPN gateways outside your NAT box as well; admin beware. If that opens up your connections so that you can connect out from your "local" hosts to your "remote" clients once they're in on the VPN, then you'll probably need to do some scripting within the phase1_up script to identify what network racoon thinks is at the remote end of the tunnel (from the SAD entries; use setkey -d) and then create/delete specific "iptables nat POSTROUTING" entries at up/down in order to more tightly control what packets get sent via ESP without NAT. That, or assign an IP address range (say, 172.16.242.0/24) via mode_cfg, set one group of statements in iptables, and work your client racoonctl script so that if, say, the client just happens to have hit the network jackpot and is on a 172.16.242.0/24 network, they tunnel all traffic via the VPN when it's connected. Whichever one you find easier. -- Troy |