Matthew Closson wrote: > On Tue, 4 Jul 2006, Stephen Bosch wrote: > >> Stephen Bosch wrote: >>> Hi, all: >>> >>> I am configuring an IPsec tunnel like so: >>> >>> local_internal_IP -> alias_IP ->remote_peer_IP -> remote_internal_IP >>> local host | openBSD | Cisco PIX | remote internal host >>> >>> alias_IP is a carp alias. It is one end of an IPsec security >>> association. netstat -rn gives this (altered) output: >>> >>>> Encap: >>>> Source Port Destination Port Proto >>>> SA(Address/Proto/Type/Direction) >>>> remote_internal_subnet/23 0 alias_IP/32 0 0 >>>> remote_peer_IP/50/use/in >>>> alias_IP/32 0 remote_internal_subnet/23 0 0 >>>> remote_peer_IP/50/require/out >>> >>> The SA is coming up. >>> >>> I am natting over the alias_IP with this line: >>> >>> "nat on $enc_if from $local_internal_IP to any -> $alias_IP" >>> >>> (to pre-empt misunderstanding, I have also tried >>> >>> "nat on $ext_if from $local_internal_IP to any -> $alias_IP") >>> >>> From the OpenBSD box, I can ping remote_internal_IP like so: >>> >>> "ping -I alias_IP remote_internal_IP" >>> >>> When pinging from the local host, however, pings time out. >> >>> >>> It would appear that there is a problem with natting. >> >> The ping works even with all the NAT lines commented out, so it looks >> like the nat isn't doing anything at all... >> >> -Stephen- >> >> > > I don't think what you want to do is currently possible: > > Here is your problem: > > Let's say you have these settings > > internal_host 10.0.0.5 > internal_openbsd_nic 10.0.0.1 > external_openbsd_nic AAA.AAA.AAA.AAA > > Remote_concentrator BBB.BBB.BBB.BBB > Remote_internal_host 192.168.0.10 > > and they say they need you to look like you are coming from 192.168.0.5 > (it happens frequently because of the other side's policy or poor > planning). > > So you think no problem, you configure isakmpd and bring up an SA between > > 192.168.0.5 <--- IPSEC_SA ---> 192.168.0.10 > > You setup an IP alias on one of your NIC's and assign it that address, > then you think you can do NAT on your enc0. But you can't. Because > here is what happens: > > 1. packet comes in from 10.0.0.5 -> 10.0.0.1 destined for 192.168.0.10 > 2. your box looks at it to see if it matches an existing flow in the > Security Association Database (SADB). It does NOT. You have a flow > between 192.168.0.5 and 192.168.0.10, NOT between 10.0.0.5 and > 192.168.0.10. So at this point there is no further route to get to that > destination and the packet is dropped. It never reaches your enc0 > interface to actually get NAT'd because it FIRST has to match a flow.
Also, if this is true, why isn't the OpenBSD device responding to 10.0.0.5 with an ICMP "no route to host" message? Ping from 10.0.0.5 to 192.168.0.10 is showing up in tcpdump output from AAA.AAA.AAA.AAA. -Stephen-
