[Openswan Users] Tunnel failing to come up

[Managed Pvt nets]

On 22/01/2015 2:43:38 AM, "Neal Murphy" <neal.p.murphy at alum.wpi.edu> 
wrote:

>
>>  ==>Left Side (Which I am managing)
>>
>>  Debian GNU/Linux 7.0.0 Wheezy
>>  Linux hostname 3.2.0-4-amd64
>>  Linux Openswan U2.6.37/K3.2.0-4-amd64 (netkey)
>>
>>
>>  ==>Right Side (Provider Side)
>>
>>  Windows Server 2008R2
>>  Microsoft Forefront TMG
>>
>>  Both sides have a
>>  Phase 1
>>  Pre-Shared Key, 3des-sha1
>>
>>  Phase 2
>>  3des-sha1
>>
>>  My tunnel just wont come up. I have checked with:
>>
>>  ========
>>  # ipsec verify
>>  Checking your system to see if IPsec got installed and started
>>  correctly:
>>  Version check and ipsec on-path [OK]
>>  Linux Openswan U2.6.37/K3.2.0-4-amd64 (netkey)
>>  Checking for IPsec support in kernel [OK]
>>    SAref kernel support [N/A]
>>    NETKEY: Testing XFRM related proc values [OK]
>>           [OK]
>>           [OK]
>>  Checking that pluto is running [OK]
>>    Pluto listening for IKE on udp 500 [OK]
>>    Pluto listening for NAT-T on udp 4500 [OK]
>>  Two or more interfaces found, checking IP forwarding [OK]
>>  Checking NAT and MASQUERADEing [OK]
>>  Checking for 'ip' command [OK]
>>  Checking /bin/sh is not /bin/dash [OK]
>>  Checking for 'iptables' command [OK]
>>  Opportunistic Encryption Support
>>  [DISABLED]
>>  # service ipsec status
>>  IPsec running - pluto pid: 2780
>>  pluto pid 2780
>>  No tunnels up
>>  #ipsec auto --status
>>  [snip/...]
>>  000 #1: "tunnel1":500 STATE_MAIN_I1 (sent MI1, expecting MR1); none 
>>in
>>  -1s; nodpd; idle; import:admin initiate
>>  000 #1: pending Phase 2 for "tunnel1" replacing #0
>>  000
>>  ========
>>
>>  This Debian box is running NAT, and the Debian box is the gateway 
>>behind
>>  the main router leading up to the internet as follows:
>>
>>
>>  ((left lan))-->{{Debian Linux with Openswan +
>>  Nat}}-->[router]--><<internet>><--[MS 2008 Forefront]
>>
>>  Would appreciate some guides on how I can go about this.
>
>Your 'outer' router may need to forward port 500 and UDP port 4500 to 
>your
>system. It may also need to allow protocol 50 (ESP) inbound. And it may 
>need
>to allow them outbound.
>
>More likely you need to use forceencaps=yes in your ipsec config to 
>tell pluto
>to use only port 4500 (NAT-Traversal) for that VPN. And you may need
>auto=start to ensure that your end starts the VPN; otherwise *your* 
>pluto may
>wait forever for start packets that never arrive because of the 
>intervening
>NAT (or double-NAT) on your end.

Thanks Neal,

Fortunately this has been done. Maybe my tcpdump may help shed some 
light:

===
tcpdump -tnli eth1 port 4500
tcpdump: verbose output suppressed, use -v or -vv for full protocol 
decode
listening on eth1, link-type EN10MB (Ethernet), capture size 65535 bytes
IP right.public.ip.4500 > 192.168.0.2.4500: NONESP-encap: isakmp: phase 
1 ? ident[E]
IP right.public.ip.4500 > 192.168.0.2.4500: NONESP-encap: isakmp: phase 
1 ? ident[E]
IP right.public.ip.4500 > 192.168.0.2.4500: NONESP-encap: isakmp: phase 
1 ? ident[E]
IP right.public.ip.4500 > 192.168.0.2.4500: NONESP-encap: isakmp: phase 
1 ? ident[E]
^C
4 packets captured
4 packets received by filter
0 packets dropped by kernel
---
---
tcpdump -tnli eth1 port 500
tcpdump: verbose output suppressed, use -v or -vv for full protocol 
decode
listening on eth1, link-type EN10MB (Ethernet), capture size 65535 bytes
IP right.public.ip.500 > 192.168.0.2.500: isakmp: phase 1 I ident
IP right.public.ip.500 > 192.168.0.2.500: isakmp: phase 1 I ident
IP right.public.ip.500 > 192.168.0.2.500: isakmp: phase 1 I ident
IP right.public.ip.500 > 192.168.0.2.500: isakmp: phase 1 I ident
IP right.public.ip.500 > 192.168.0.2.500: isakmp: phase 1 I ident
^C
5 packets captured
5 packets received by filter
0 packets dropped by kernel
===

It would seem like my ipsec is failing to respond to the right side 
public ip (Microsoft) packets coming through. But I could be wrong. What 
do you think I could be missing?

many thanks again,

MPN.




>