From: Michael Gale <michael.gale@utilitran.com>
To: Ola Nilsson <ola@fam-nilsson.org>, netfilter@lists.netfilter.org
Subject: Re: IPSec through my firewall
Date: Tue, 15 Feb 2005 08:38:33 -0700 [thread overview]
Message-ID: <42121779.4000907@utilitran.com> (raw)
In-Reply-To: <87vf8tq2fx.fsf@helmut.nilsson.homedns.org>
Hello,
This all depends on your implementation, I believe the standard
protocol 50 (ESP) traffic still does not support NAT. But there are a
lot of vendors out there that have NAT "aware" VPN devices.
Some devices use UDP encapsulation, others allow a more relaxed version
of the IPSEC protocol to handle the NAT.
Some only support NAT during one point in the connection, so both the
client and server can't use NAT, only one or the other.
From the RFC's:
--snip--
Negotiation of the NAT-Traversal Encapsulation
The negotiation of the NAT-Traversal happens by adding two new
encapsulation modes. These encapsulation modes are
UDP-Encapsulated-Tunnel 3
UDP-Encapsulated-Transport 4
It is not normally useful to propose both normal tunnel or transport
mode and UDP-Encapsulated modes. UDP encapsulation is required to
fix the inability to handle non-UDP/TCP traffic by NATs (see
[RFC3715], section 2.2, case i).
If there is a NAT box between hosts, normal tunnel or transport
encapsulations may not work. In this case, UDP-Encapsulation SHOULD
be used.
--snip--
I would allow all traffic between the client and server on UDP ports 500
and 4500.
iptables -I -i EXT_FACE -o VPN_FACE -d X.X.X.X -p udp --dport 500 -j ACCEPT
iptables -I -i EXT_FACE -o VPN_FACE -d X.X.X.X -p udp --dport 4500 -j ACCEPT
Michael.
Ola Nilsson wrote:
> Hie,
>
> I would've tried something different if I had the possibility to
> choose. This is a solution chosen by the company I work for.
>
> Are you sure about that IPSec can't be NATed? NAT-T is kind of meant to
> handle just that. Also, my colleagues have no trouble through
> e.g. D-Link routers. The ISAKMP part NATs just fine...
>
> Regards,
> /Ola
>
> Michael Gale <michael.gale@utilitran.com> writes:
>
>
>>Hello,
>>
>> You can not NAT ESP (protocol 50) traffic. Some IPSEC clients
>>and servers support NATing but I believe this requires special
>>implementation on the client and server end.
>>
>>If you want to NAT a VPN tunnel I suggest you try a SSL base
>>VPN. OpenVPN works well, you could also try TCP or UDP encapsulation
>>to help get around the NAT issue.
>>
>>Michael.
>
>
--
Michael Gale
Lan Administrator
Utilitran Corp.
Hey, let me file that under important .... > /dev/null
...
"Hey did you read my e-mail"
"Let my check"
^From:.* > /dev/null
"Nope, I missed it, send it again"
next prev parent reply other threads:[~2005-02-15 15:38 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-02-15 10:25 IPSec through my firewall Ola Nilsson
2005-02-15 14:46 ` Michael Gale
2005-02-15 15:15 ` Ola Nilsson
2005-02-15 15:38 ` Michael Gale [this message]
2005-02-15 15:07 ` Jason Opperisano
2005-02-15 22:00 ` Ola Nilsson
[not found] <200502151715.j1FHFtfO029324@pepsi.fishpuppy.com>
2005-02-16 9:29 ` rowdy
2005-02-16 10:27 ` Georgi Alexandrov
2005-02-16 12:46 ` Ola Nilsson
2005-02-16 14:59 ` Jean Caron
2005-02-16 18:08 ` Ola Nilsson
-- strict thread matches above, loose matches on Subject: below --
2005-02-16 14:03 Samuel Jean
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=42121779.4000907@utilitran.com \
--to=michael.gale@utilitran.com \
--cc=netfilter@lists.netfilter.org \
--cc=ola@fam-nilsson.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.