[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Masquerading IPSec connections on FreeBSD?
On Fri, Sep 06, 2002 at 10:23:45AM +0300, Patrick J Okui wrote:
> windows IPSEC client(By Galileo)
> (private ip address) <=======
> || ||
> || ||
> Un*x Gateway/Firewall ||
> (clients global IP address) || tunnel is set up
> || || seamlessly between
> || || these two machines
> || || just as if the win
> INTERNET || machine had a global
> || || ip address.
> || ||
> Remote IPSEC server (Galileo software)<===
> (Global IP address)
>
>
> So, the problem I was having is that on linux, this setup would not work
> for the IPSEC client - which would claim that the remote server is not
> replying... (since its packets were being dropped). The question is, how
> do I get FreeBSD to work as the Firewall - AND correctly pass the IPSEC
> packets... unless I misunderstood your reply...
>
> Is this possible or am I just dreaming? :-)
Well, it may be possible. The ipfilter masquerading config I sent before
should be able to masquerade all protocols, including ESP (IP protocol 50).
The issues are:
- ESP does not have a 'port number' like TCP or UDP, so only one client can
be masquerading ESP at any one time. (Actually that's not entirely true; it
has a field called 'SPI', but I don't know of any masquerading
implementation which makes use of it)
- All sessions must be initiated by the client, and needs to exchange
packets at least often enough to stop the NAT state timing out.
Both of these issues could be solved by using static NAT, i.e. one public IP
address for each internal client, or using a pool of public IPs on the
outside of the firewall.
But actually, in that case, you might be better just setting up a separate
LAN on public IPs (but behind the firewall) for IPSEC clients to use:
outside
^
|
-------- firewall -----------
public private
A /28 of public IPs would let you have 13 simultaneous clients using IPSEC,
and no NAT is required. You can still use DHCP on that subnet of course. So
the only difference from the client's point of view is which network port
they plug into.
Another possible problem with NAT is whether the 'real' IP address of the
client is embedded anywhere in the setup/key exchange part of the session. I
don't know if it is or not, but if it were, it would need special IPSEC
support in the proxy.
You might find it's easier to configure your client to use a different
tunnelling protocol such L2TP; at least in that case all the session setup
is "in-band" within the same tunnel (whereas with IPSEC you have UDP port
500 for the key exchange and then ESP for the data packets)
Cheers,
Brian.
-----
This is the afnog mailing list, managed by Majordomo 1.94.5
To send a message to this list, e-mail afnog at afnog.org
To send a request to majordomo, e-mail majordomo at afnog.org and put
your request in the body of the message (i.e use "help" for help)
This list is maintained by owner-afnog at afnog.org