[Openswan Users] Openswan behind NAT <-> public IP connectivity issue.

[phearnomore]

2009/12/11 phearnomore <phearnomore at gmail.com>:
> Hello.
>
> The network scenerio I've been working on today is as follows:
>
> Windows (10.50.50.3) \
> Openswan (10.50.50.2) <-> (10.50.50.1) Cisco IOS(NAT) (100.100.100.1)
> <=> (200.200.200.1) Windows (Shrew VPN Client)
>
> ***Cisco configuration (VPN-related):***
>
> ip nat inside source list NAT interface Dialer0 overload
> ip nat inside source static udp 10.50.50.2 4500 interface Dialer0 4500
> ip nat inside source static udp 10.50.50.2 500 interface Dialer0 500
>
> ip access-list extended FIREWALL
>  permit udp any any eq isakmp
>  permit udp any any eq non500-isakmp
>  permit esp any any
>  deny   ip any any log
> ip access-list extended NAT
>  permit ip 10.50.50.0 0.0.0.255 any
>  deny   ip any any
>
> ***Openswan***
>
> config setup
>  nat_traversal=yes
>  oe=off
>  protostack=netkey
> conn phearnomore
>  authby=secret
>  pfs=no
>  left=%defaultroute
>  leftsubnet=10.50.50.0/24
>  right=%any
>  auto=add
>
> ***Shrew VPN Client***
>
> I could paste the text file with the configuration parameters but if
> you've never used it, it might be confusing so I'll just describe it
> in my own words:
>
> Autoconfiguration of any kind is DISABLED. I use the (only)
> 200.200.200.1 interface to set up the connection (NOT using the
> virtual interface). Apart from using "Mutual PSK", changing aggresive
> mode to main mode and including the 10.50.50.0/24 in the list of
> networks that are supposed to go through the VPN, everything else is
> in default setup (AUTO mainly) - besides the problem isn't with the
> security association so it doesn't really matter I guess.
>
> So logs from Openswan look like this:
>
> [...]
>
> Dec 11 14:52:48 ubuntu pluto[1212]: packet from 200.200.200.1:500:
> received Vendor ID payload [Cisco-Unity]
> Dec 11 14:52:48 ubuntu pluto[1212]: "phearnomore"[1] 83.10.39.123 #1:
> responding to Main Mode from unknown peer 200.200.200.1
> Dec 11 14:52:48 ubuntu pluto[1212]: "phearnomore"[1] 83.10.39.123 #1:
> transition from state STATE_MAIN_R0 to state STATE_MAIN_R1
> Dec 11 14:52:48 ubuntu pluto[1212]: "phearnomore"[1] 83.10.39.123 #1:
> STATE_MAIN_R1: sent MR1, expecting MI2
> Dec 11 14:52:49 ubuntu pluto[1212]: "phearnomore"[1] 83.10.39.123 #1:
> NAT-Traversal: Result using RFC 3947 (NAT-Traversal): i am NATed
> Dec 11 14:52:49 ubuntu pluto[1212]: "phearnomore"[1] 83.10.39.123 #1:
> transition from state STATE_MAIN_R1 to state STATE_MAIN_R2
> Dec 11 14:52:49 ubuntu pluto[1212]: "phearnomore"[1] 83.10.39.123 #1:
> STATE_MAIN_R2: sent MR2, expecting MI3
> Dec 11 14:52:49 ubuntu pluto[1212]: "phearnomore"[1] 83.10.39.123 #1:
> Main mode peer ID is ID_IPV4_ADDR: '200.200.200.1'
> Dec 11 14:52:49 ubuntu pluto[1212]: "phearnomore"[1] 83.10.39.123 #1:
> transition from state STATE_MAIN_R2 to state STATE_MAIN_R3
> Dec 11 14:52:49 ubuntu pluto[1212]: "phearnomore"[1] 83.10.39.123 #1:
> new NAT mapping for #1, was 200.200.200.1:500, now 200.200.200.1:4500
> Dec 11 14:52:49 ubuntu pluto[1212]: "phearnomore"[1] 83.10.39.123 #1:
> STATE_MAIN_R3: sent MR3, ISAKMP SA established
> {auth=OAKLEY_PRESHARED_KEY cipher=aes_256 prf=oakley_md5
> group=modp3072}
> Dec 11 14:52:49 ubuntu pluto[1212]: "phearnomore"[1] 83.10.39.123 #1:
> ignoring informational payload, type IPSEC_INITIAL_CONTACT
> msgid=00000000
> Dec 11 14:52:49 ubuntu pluto[1212]: "phearnomore"[1] 83.10.39.123 #1:
> received and ignored informational message
> Dec 11 14:52:58 ubuntu pluto[1212]: "phearnomore"[1] 83.10.39.123 #1:
> the peer proposed: 10.50.50.0/24:0/0 -> 200.200.200.1/32:0/0
> Dec 11 14:52:58 ubuntu pluto[1212]: "phearnomore"[1] 83.10.39.123 #2:
> responding to Quick Mode proposal {msgid:0362d7a5}
> Dec 11 14:52:58 ubuntu pluto[1212]: "phearnomore"[1] 83.10.39.123 #2:
>   us: 10.50.50.0/24===10.50.50.2[+S=C]
> Dec 11 14:52:58 ubuntu pluto[1212]: "phearnomore"[1] 83.10.39.123 #2:
>  them: 200.200.200.1[+S=C]
> Dec 11 14:52:58 ubuntu pluto[1212]: "phearnomore"[1] 83.10.39.123 #2:
> transition from state STATE_QUICK_R0 to state STATE_QUICK_R1
> Dec 11 14:52:58 ubuntu pluto[1212]: "phearnomore"[1] 83.10.39.123 #2:
> STATE_QUICK_R1: sent QR1, inbound IPsec SA installed, expecting QI2
> Dec 11 14:52:58 ubuntu pluto[1212]: "phearnomore"[1] 83.10.39.123 #2:
> transition from state STATE_QUICK_R1 to state STATE_QUICK_R2
> Dec 11 14:52:58 ubuntu pluto[1212]: "phearnomore"[1] 83.10.39.123 #2:
> STATE_QUICK_R2: IPsec SA established tunnel mode {ESP=>0x8ddac692
> <0x61e91123 xfrm=AES_256-HMAC_MD5 NATOA=none NATD=200.200.200.1:4500
> DPD=none}

Just noticed it now. 83.10.39.123 which appears through the log after
each "..ubuntu pluto[1212]: "phearnomore"..." is, *of course*,
supposed to be 200.200.200.1. It's a dial-up IP which was supposed to
be an easy, *made-up* IP for clarity.

> Looks nice, right? Well, while I can ping 10.50.50.2 (Openswan), I
> cannot ping 10.50.50.1 (Cisco), nor 10.50.50.3 (Windows). "echo 1 >
> /proc/sys/net/ipv4/ip_forward" was executed on the Openswan system.
> I'm out of ideas. I spent some time looking through the mailing-list
> to find similar problems and...I did find few but they were either
> unsolved due to the lack of interest of the asking party or the
> solution went in a strange direction which I though could not have
> been the case when it comes to the problem I'm experiencing. I assume
> it's something trivial, I just cannot see it now. Any kind of
> suggestion, apart from give up;), will be appreciated.

Oh, and maybe it'll be useful (it might be a routing/switching issue
after all) - both Windows and Openswan are plugged into a build-in
switch of the Cisco Router (800 series).

> Thanks and cheers,

Cheers again, ;)

-- 
phearnomore