[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: IPSEC and IPNAT on OpenBSD 2.9
You'r VPN is between 10.0.0.64 and 10.0.0.1 only, i.e only packets
matching this will be encapsulated in IPsec. A packet sent to any other
address will not. The fact that the W2K box matches this anyway (and
sends it encapsulated) must be because of some magic option. :)
If you want to tunnel all traffic, you should use something like 10.0.0.64
to 0.0.0.0/0, i.e tunnel everything from 10.0.0.64 to "default". If you do
this, the OpenBSD box will match the returning traffic, and encapsulate
these packets also.
Also, I'm not quite clear where you are using NAT in the below picture?
Are you NAT:in 10.0.0.0/NN or 10.6.X.Y/NN ? From your example, I'm
assuming its 10.0.0.0 that is the NAT:ed network, i.e you hide it behind
the 10.6.6.145 address. If so, the above should work just fine. I've run
similar setups without problems.
/H
On Fri, 22 Feb 2002, Austin Godber wrote:
> Hello,
> I have been trying to get IPSEC and IPNAT working together on the same
> OpenBSD 2.9 gateway with a Windows 2000 client machine. I am using
> ISAKMPD and the Windows 2000 IPSec implementation. I have no trouble
> communicating between the gateway and the windows client but when the
> the client tries to go beyond the gateway the traffic doesn't make it
> back.
>
> Here is my setup:
>
>
> OpenBSD 2.9 w/ NAT Windows 2k
> +----------+ +----------------------+ +---------+
> | 10.6.6.7 |----|10.6.6.145 10.0.0.1|======|10.0.0.64|
> | | | (ne3) (wi0) | +---------+
> +----------+ +----------------------+
> ^ ^
> | |
> tunnel endpoints
>
>
> Using tcpdump I can see a ping packet do this:
>
> 10.0.0.64->wi0(ESP)->ne3->10.6.6.7->ne3->wi0(no ESP)
>
> Since the echo reply doesn't get stuffed onto enc0 on the return trip it
> is dropped by the win2k host.
>
> I do realize the strangeness with IPNAT and IPSEC both working in the ip
> stack at different places ... well, its only strangeness since I don't
> fully understand it. Does this fall into the category of things that
> can't be done?
>
> Thanks for your help. I hope I am not asking a question that has
> already been asked, I tried to find a solution.
> -Austin
>
> --
> Austin Godber
> godber@asu.edu.delete.me
> Rotten Philomathian
>
>
> Config Files:
>
> /etc/ipf.rules:
> pass through ... both ways
>
> /etc/ipnat.rules
> map ne3 enc0/8 -> ne3/32 portmap tcp/udp 10000:20000
> map ne3 enc0/8 -> ne3/32
>
> /etc/isakmpd/isakmpd.policy
> KeyNote-Version: 2
> Authorizer: "POLICY"
>
> /etc/isakmpd/isakmpd.conf
> [Phase 2]
> Connections= IPSec-Conn-bsd_box-win2k_box
>
> [ISAKMP-peer-node-win2k_box]
> Phase= 1
> Transport= udp
> Address= 10.0.0.64
> Configuration= Windows-main-mode
> Authentication= sharedsecret
>
> [IPSec-Conn-bsd_box-win2k_box]
> Phase= 2
> ISAKMP-peer= ISAKMP-peer-node-win2k_box
> Configuration= Windows-quick-mode
> Local-ID= Addr-bsd_box
> Remote-ID= Addr-win2k_box
>
> [Addr-win2k_box]
> ID-type= IPV4_ADDR
> Address= 10.0.0.64
>
> [Addr-bsd_box]
> ID-type= IPV4_ADDR
> Address= 10.0.0.1
>
> [Windows-main-mode]
> DOI= IPSEC
> EXCHANGE_TYPE= ID_PROT
> Transforms= 3DES-SHA
>
> [Windows-quick-mode]
> DOI= IPSEC
> EXCHANGE_TYPE= QUICK_MODE
> Suites= QM-WINDOWS-SUITE
>
> [QM-WINDOWS-SUITE]
> Protocols= QM-WINDOWS-PROTOS
>
> [QM-WINDOWS-PROTOS]
> PROTOCOL_ID= IPSEC_ESP
> Transforms= QM-WINDOWS-XF
>
> [QM-WINDOWS-XF]
> TRANSFORM_ID= 3DES
> ENCAPSULATION_MODE= TUNNEL
> AUTHENTICATION_ALGORITHM= HMAC_SHA
>
>
--
Håkan Olsson <ho@crt.se> (+46) 708 437 337 Carlstedt Research
Unix, Networking, Security (+46) 31 701 4264 & Technology AB