IPSec passthrough with iptables

[Thomas Smith]

I need to be able to connect to clients IPSec VPN from
behind and iptables firewall. I know the VPN is
working and my firewall is masquing traffic but IPSec
doesn't work from systems behind my firewall.

I've got a pretty basic firewall. It's simply masquing
internal traffic.

Are there some iptables' rules or patches I'm missing?

Tom
***@yahoo.com

[Sneppe Filip]

Hi,

Post by Thomas Smith
I need to be able to connect to clients IPSec VPN from
behind and iptables firewall. I know the VPN is
working and my firewall is masquing traffic but IPSec
doesn't work from systems behind my firewall.
I've got a pretty basic firewall. It's simply masquing
internal traffic.
Are there some iptables' rules or patches I'm missing?

Well, you only need to allow udp port 500 traffic for IKE,
and protocols 50 (ESP) and 51 (AH).

However, you will find that most types of AH and NAT don't
mix all that well, unless you do some really clever (read:
hackish) NAT tricks. Basically, the IP addresses on both
sides may not be NAT'ted. If you use NAT, you must NAT the
addresses back before they reach the other side.

Regards,
Filip

[Antony Stone]

Post by Thomas Smith
I need to be able to connect to clients IPSec VPN from
behind and iptables firewall. I know the VPN is
working and my firewall is masquing traffic but IPSec
doesn't work from systems behind my firewall.
I've got a pretty basic firewall. It's simply masquing
internal traffic.
Are there some iptables' rules or patches I'm missing?

No patches needed. No special support in netfilter needed.

Make sure you are forwarding (both ways :-) protocol 50 (ESP), protocol 51
(AH) and UDP sport 500 / dport 500 (IKE).

Also make sure you are using IPsec in tunnel mode, not transport mode
(transport mode will not work through NAT).

Hope this helps,

Antony.

[George Agnelli]

I'm having a similar problem and am not very experienced yet with iptables.

Post by Antony Stone
Make sure you are forwarding (both ways :-) protocol 50 (ESP), protocol 51
(AH) and UDP sport 500 / dport 500 (IKE).

Could you show me the best way to write this in iptables syntax?

George

[Antony Stone]

Post by George Agnelli
I'm having a similar problem and am not very experienced yet with iptables.

Post by Antony Stone
Make sure you are forwarding (both ways :-) protocol 50 (ESP), protocol
51 (AH) and UDP sport 500 / dport 500 (IKE).

Could you show me the best way to write this in iptables syntax?

iptables -A FORWARD -p esp -j ACCEPT
iptables -A FORWARD -p ah -j ACCEPT
iptables -A FORWARD -p udp --sport 500 --dport 500 -j ACCEPT

You may wish to add some -s and/or -d source & destination address
restrictions on the above rules, eg:

iptables -A FORWARD -p esp -s a.b.c.d -d w.x.y.z -j ACCEPT
iptables -A FORWARD -p esp -s w.x.y.z -d a.b.c.d -j ACCEPT

where a.b.c.d and w.x.y.z are the two IPsec gateways which need to
communicate.

Antony.
--
This email is intended for the use of the individual addressee(s) named above
and may contain information that is confidential, privileged or unsuitable
for overly sensitive persons with low self-esteem, no sense of humour, or
irrational religious beliefs.

If you have received this email in error, you are required to shred it
immediately, add some nutmeg, three egg whites and a dessertspoonful of
caster sugar.   Whisk until soft peaks form, then place in a warm oven for 40
minutes.   Remove promptly and let stand for 2 hours before adding some
decorative kiwi fruit and cream.   Then notify me immediately by return email
and eat the original message.

[David A Golden]

Just to muddy the waters, through experimentation, I have found that using
Checkpoint SecuRemote (on windows) behind a Linux netfilter firewall, I can
achieve an IPSEC connection using just:

iptables -A FORWARD -s $INTERNAL_NET -j ACCEPT
iptables -A FORWARD -d $INTERNAL_NET -m state --state ESTABLISHED,RELATED \
-j ACCEPT

I.e. explicit per-protocol forwarding seems unnecessary. (Though you might
want to be explicit for security/control reasons.) [Note, no UDP
encapsulation, either]

I do experience weird time-outs occasionally, apparently connected to
incoming IKE packets (UDP port 500) that aren't recognized as connected,
but I can get around this by just accepting them to the firewall, which
does nothing as there is nothing running on that port. (I'm trying
variations of reject/drop to see if there is a better way to reply.)

Regards,
David

Post by Antony Stone

Post by George Agnelli
I'm having a similar problem and am not very experienced yet with iptables.

Post by Antony Stone
Make sure you are forwarding (both ways :-) protocol 50 (ESP), protocol
51 (AH) and UDP sport 500 / dport 500 (IKE).

Could you show me the best way to write this in iptables syntax?

iptables -A FORWARD -p esp -j ACCEPT
iptables -A FORWARD -p ah -j ACCEPT
iptables -A FORWARD -p udp --sport 500 --dport 500 -j ACCEPT
You may wish to add some -s and/or -d source & destination address
iptables -A FORWARD -p esp -s a.b.c.d -d w.x.y.z -j ACCEPT
iptables -A FORWARD -p esp -s w.x.y.z -d a.b.c.d -j ACCEPT
where a.b.c.d and w.x.y.z are the two IPsec gateways which need to
communicate.
Antony.

[Antony Stone]

Post by David A Golden
Just to muddy the waters, through experimentation, I have found that using
Checkpoint SecuRemote (on windows) behind a Linux netfilter firewall, I can
iptables -A FORWARD -s $INTERNAL_NET -j ACCEPT
iptables -A FORWARD -d $INTERNAL_NET -m state --state ESTABLISHED,RELATED \
-j ACCEPT
I.e. explicit per-protocol forwarding seems unnecessary. (Though you might
want to be explicit for security/control reasons.)

Well, quite.

We suggested some rules which would allow IPsec through your firewall, but
which would at least block a few other protocols. We also weren't sure
whether you were initiating the IPsec connection from the inside or the
outside of your firewall (it's clearly the inside, if the above rules work).

If you prefer to allow *every* protocol out of your network, then this
includes IPsec, so you don't need to do anything specific.

Good that you have things working - now to consider how secure you want it...

Antony.