Connection to SonicWall VPN through Linux IPTABLES Firewall/Proxy
ajke...@gmail.com
I've set up a very simple iptables firewall/proxy box and have been
unable to connect to a SonicWall VPN server from behind that box. This
problem seems to have come up several times in this newsgroup and
others but none of the posted suggestions have helped.
The connection is failing at the initial stage--the error is "The Peer
is not responding to phase 1 ISAKMP requests," which I understand to be
a generic error that doesn't give much insight into the problem.
The relevant rules on the proxy linux box are as follows:
iptables -A FORWARD -i eth1 -o eth0 -j ACCEPT
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
(where eth0 faces the WAN and eth1 faces the LAN).
So it's about as simple as you can get. I previously used a DSL router
to do NAT and that worked fine without any special configuration--so
what is different in my simple iptables setup from that router?
I was informed by sysadmin that UDP port 500 needs to be forwarded, so
I tried this additionally:
iptables -A INPUT -p udp -i eth0 --sport 500 --dport 500 -j ACCEPT
iptables -A OUTPUT -p udp -o eth0 --sport 500 --dport 500 -j ACCEPT
and also:
iptables -A INPUT -p 50 -i eth0 -j ACCEPT
iptables -A OUTPUT -p 50 -o eth0 -j ACCEPT
But none of those additional rules affected the result. I'm not even
clear why they would be necessary if the proxy is forwarding all
packets.
I'd appreciate any advice about how to troubleshoot this.
(In case it's not obvious--the SonicWALL VPN Client is running on a
Windows box).
Running Debian sarge, kernel 2.6.8.
Nigel Wade
What protocol does the SonicWALL use for VPN? You might need to forward IP
protocol 47 (GRE).
If you don't specify one, the defaults are UDP, TCP and ICMP.
--
Nigel Wade, System Administrator, Space Plasma Physics Group,
University of Leicester, Leicester, LE1 7RH, UK
E-mail : n...@ion.le.ac.uk
Phone : +44 (0)116 2523548, Fax : +44 (0)116 2523555
ajke...@gmail.com
understand is why the rule
iptables -A FORWARD -i eth1 -o eth0 -j ACCEPT
Isn't sufficient to cover everything? That will forward all protocols
and all ports, right? Or am I misunderstanding something?
Wolfgang Kueter
> (cross-posting from comp.os.linux.networking, where I got no replies):
>
> I've set up a very simple iptables firewall/proxy box
You are clueless, having installed something that you don't understand.
> and have been
> unable to connect to a SonicWall VPN server from behind that box. This
> problem seems to have come up several times in this newsgroup and
> others but none of the posted suggestions have helped. [...]
General approach: Hire a skilled professional and pay him. He will
systematically deal with your problem. In general his approach will be:
- Find out your requirements.
- Choose the right tools for the job
- Install and configure them by watching their behaivior (and the logs
in case of debugging).
> The relevant rules on the proxy linux box are as follows:
iptables is packet filtering, proxy is something else.
> iptables -A FORWARD -i eth1 -o eth0 -j ACCEPT
> iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
Fine, NAT for the net, has nothing to do with VPN.
> iptables -A INPUT -p 50 -i eth0 -j ACCEPT
> iptables -A OUTPUT -p 50 -o eth0 -j ACCEPT
That might indicate that the VPN shall terminate on the Linux box.
In general: the iptables bits you posted show, that you absolutely
have no clue about IPSeC but strong need for someone who has. Hire such a
person, pay him.
Wolfgang
Wolfgang Kueter
> My sysadmin told me he thought it was UDP port 500. What I don't
> understand is why the rule
>
> iptables -A FORWARD -i eth1 -o eth0 -j ACCEPT
>
> Isn't sufficient to cover everything?
The filter table is *not* the nat table.
RTFM, man iptables.
> That will forward all protocols
> and all ports, right?
It allows all traffic everything entering the box on interface
eth1 and leaving it on eth0 with source and destination IP beeing
different from the IP-adresses of the box itself.
> Or am I misunderstanding something?
Yes, you misunderstand almost everything, even such iptables basics
as described at:
http://www.netfilter.org/documentation/HOWTO//packet-filtering-HOWTO-6.html
Wolfgang
ajke...@gmail.com
I'm not sure why you need to start off with a personal insult--I'm just
trying to figure this out. I would never install something I didn't
fully understand on a production system for a network environment--but
I've just installed and set up something for myself at home. This is
how most people learn.
> General approach: Hire a skilled professional and pay him.
I'm not sure you understand what I'm trying to do: I am replacing a
standard router with a Linux box. It does two things: takes all traffic
from the LAN and does NAT to provide access to the Internet to the
internal machines; and filters inbound packets to the proper internal
machine. If it were a corporate work environment, I would have a
professional set it up with regular security audits, etc... But I
expect very few people who are trying to set up a router for their home
are going to hire a professional for that relatively simple task,
especially when the point is to learn how it works.
> iptables is packet filtering, proxy is something else.
Proxy -- e.g., http://webmaster.lycos.co.uk/glossary/P/ "Server placed
between a user's machine and the Internet."
What iptables is doing is taking packets from the LAN, forwarding them
to the WAN, and mangling the source IP to be the WAN IP. How is this
not proxying? Do you distinguish between proxy and gateway? If so, how?
Why are there hundreds of thousands of pages in Google describing how
to use iptables as a transparent proxy? Is everyone misusing the term?
Having read the rest of your comments, I think you've misunderstood my
question. I have a perfectly functional gateway/proxy or whatever you
want to call it. Every box within the LAN gets the linux box as its
gateway from a DCHP server. That box also directs inbound packets
depending on IP address and port to different machines in the LAN,
entirely separate from the NAT functionality.
All I'm trying to figure out is why a SonicWALL VPN client on an
internal machine can't connect to a VPN server outside the LAN. I have
read the netfilters webpage, the iptables manpage, and the iptables
documentation in /usr/share/doc. I've also googled for this combination
of services and found other people who have this problem.
I admit I'm not an iptables expert. I do think I understand basically
what it's doing. What I don't understand is why the VPN packets aren't
reaching their destination while everything else works fine.
What I'm asking for is advice about how to troubleshoot it. Even a
link in the right direction would be helpful.
Wolfgang Kueter
>> You are clueless, having installed something that you don't understand.
>
> I'm not sure why you need to start off with a personal insult--
I just said, that you lack the neccessary knowledge.
>> General approach: Hire a skilled professional and pay him.
>
> I'm not sure you understand what I'm trying to do: I am replacing a
> standard router with a Linux box. It does two things: takes all traffic
> from the LAN and does NAT to provide access to the Internet to the
> internal machines; and filters inbound packets to the proper internal
> machine. If it were a corporate work environment, I would have a
> professional set it up with regular security audits, etc... But I
> expect very few people who are trying to set up a router for their home
> are going to hire a professional for that relatively simple task,
> especially when the point is to learn how it works.
>
>> iptables is packet filtering, proxy is something else.
>
> Proxy -- e.g., http://webmaster.lycos.co.uk/glossary/P/ "Server placed
> between a user's machine and the Internet."
>
> What iptables is doing is taking packets from the LAN, forwarding them
> to the WAN, and mangling the source IP to be the WAN IP.
This happens on layer 3 (and maybe also 2), a proxy works on layer 4.
> How is this not proxying?
Because a proxy works one (or two) layers above.
> Do you distinguish between proxy and gateway?
A proxy is a gateway working on the application layer (layer 4), a router
(and also one that does NAT) works below that.
> If so, how?
See above.
> Why are there hundreds of thousands of pages in Google describing how
> to use iptables as a transparent proxy?
Because iptables redirects packets (this can be done on layer 3) to a
server-process running on the box itself or on another box, and this
server-process process handles the request *on* *layer* *3*
> Is everyone misusing the term?
Those who have unterstood network communication do not mess up these
things.
> I admit I'm not an iptables expert.
You have no clue about basics in network communication. Therefiore you run
into problems and mess everything up.
> I do think I understand basically
> what it's doing.
Obviously you have not.
> What I don't understand is why the VPN packets aren't
> reaching their destination while everything else works fine.
Because you've messed up everything.
> What I'm asking for is advice about how to troubleshoot it.
I told you what a skilled person whould do to troubleshoot such a setup.
Read a good book about TCP IP. The 'Stevens' would be a good start. Read
the IPSeC protocol specification.
> Even a link in the right direction would be helpful.
... or hire a skilled person any pay him.
Wolfgang
ajke...@gmail.com
Wolfgang Kueter
> Thanks for your help. Does anyone else have any suggestions?
Without the neccessary knowledge you'll not be able t figure that
yourself. I told you what to read.
Wolfgang
Wolfgang Kueter
> What protocol does the SonicWALL use for VPN? You might need to forward IP
> protocol 47 (GRE).
Im pretty sure that the Sonicwall will try to use IPSeC and that means
protocols esp (50) and ah (51). And with a router NATting the
whole traffic including IPSec he'll for sure run into serious
problems. If it is IPSeC (what I assume) I strongly recomend using a VPN
endpoint with a public IP. NAT traversal is definitely no fun to configure
and using it results in the loss of security features included in IPSeC.
OpenSwan is a popular IPSeC implementation for Linux, so I really see no
reason terminating the VPN on the Sonicwall behind a NAT device.
If he likes to use the Sonicwall why does't he connect it with its
external interface to the internet? Like all similar products from other
vendors ranging from pixes over netscreens, clavisters to fortigates
and others a sonicwall is designed exactely for that purpose.
Wolfgang
Jon Dowland
news:pan.2005.11.02....@shconnect.de:
> If he likes to use the Sonicwall why does't he connect it with its
> external interface to the internet?
My mind-reading skills are a bit rusty, rather than directing the question
at everyone else, why not ask him? You'd then look vaguely helpful.
Robert
> I've set up a very simple iptables firewall/proxy box and have been
> unable to connect to a SonicWall VPN server from behind that box. This
> problem seems to have come up several times in this newsgroup and
> others but none of the posted suggestions have helped.
Without knowing how your rules are setup it would only be a guessing game
as to what is wrong.
> The relevant rules on the proxy linux box are as follows:
There are going to be more then this that are causing you your problem.
> iptables -A FORWARD -i eth1 -o eth0 -j ACCEPT
> iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
The above should be like this, you don't need the '-t nat';
iptables -A POSTROUTING -o eth0 -j MASQUERADE
> (where eth0 faces the WAN and eth1 faces the LAN).
OK on your input rules for eth1 you are going to have to accept the
connection on the ports that are required. If you really want to be
simple then do something like this;
iptables -A INPUT -i eth1 -j ACCEPT
This will accept everything on the lan interface. No need to break down
all the ports you want to allow through.
> So it's about as simple as you can get. I previously used a DSL router
> to do NAT and that worked fine without any special configuration--so
> what is different in my simple iptables setup from that router?
>
> I was informed by sysadmin that UDP port 500 needs to be forwarded, so
> I tried this additionally:
>
> iptables -A INPUT -p udp -i eth0 --sport 500 --dport 500 -j ACCEPT
> iptables -A OUTPUT -p udp -o eth0 --sport 500 --dport 500 -j ACCEPT
>
> and also:
>
> iptables -A INPUT -p 50 -i eth0 -j ACCEPT
> iptables -A OUTPUT -p 50 -o eth0 -j ACCEPT
Looks like you are allowing 500 an 50 in but not out.
I think here is where your problem is. I assume (as u me) that eth0 is
the external interface and eth1 is the internal interface. If that is the
case then you would need to change the above to this;
iptables -A INPUT -i eth0 -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -i eth1 -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -i eth1 -p udp --dport 500 -j ACCPET
iptables -A INPUT -i eht1 -p udo --dport 50 -j ACCEPT
> I'd appreciate any advice about how to troubleshoot this.
If I knew your rule set I would be able to help 100% but going on just
what you've posted isn't enough to be totally sure this is going to work.
I use a Cisco VPN client through my firewall without a problem. The key
is knowing what ports on which protocol is used.
--
Regards
Robert
Smile... it increases your face value!
----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----
ajke...@gmail.com
where I've gotten some very useful feedback and isolated (but not
solved) the problem, but I thought I should respond to your
suggestions:
Robert wrote:
> > I've set up a very simple iptables firewall/proxy box and have been
> > unable to connect to a SonicWall VPN server from behind that box. This
> > problem seems to have come up several times in this newsgroup and
> > others but none of the posted suggestions have helped.
> Without knowing how your rules are setup it would only be a guessing game
> as to what is wrong.
Actually, for the purposes of this experiment, I did post the entire
ruleset. All chains in all tables have default policy ACCEPT and no
other rules.
> There are going to be more then this that are causing you your problem.
> > iptables -A FORWARD -i eth1 -o eth0 -j ACCEPT
> > iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
> The above should be like this, you don't need the '-t nat';
> iptables -A POSTROUTING -o eth0 -j MASQUERADE
Although the masquerading is working fine. I've since replaced this
rule with an SNAT target. Given that all NAT traffic is going to
traverse the nat table, is there a reason why it is preferable to do
the SNAT'ing in filter rather than than nat?
> OK on your input rules for eth1 you are going to have to accept the
> connection on the ports that are required. If you really want to be
> simple then do something like this;
> iptables -A INPUT -i eth1 -j ACCEPT
I don't think that's actually required when the packets are being
forwarded rather than having as source or destination the NAT box. In
any case, as I mentioned above, all chains (for the purposes of
debugging) are set to policy ACCEPT.
> > I was informed by sysadmin that UDP port 500 needs to be forwarded, so
> > I tried this additionally:
> > iptables -A INPUT -p udp -i eth0 --sport 500 --dport 500 -j ACCEPT
> > iptables -A OUTPUT -p udp -o eth0 --sport 500 --dport 500 -j ACCEPT
> > and also:
> > iptables -A INPUT -p 50 -i eth0 -j ACCEPT
> > iptables -A OUTPUT -p 50 -o eth0 -j ACCEPT
> Looks like you are allowing 500 an 50 in but not out.
I've since realized that the INPUT and OUTPUT chains in the filter
table on the NAT box shouldn't matter for packets that are forwarded
and connection tracked. But again the ACCEPT rules shouldn't matter
with default policy ACCEPT.
> I think here is where your problem is. I assume (as u me) that eth0 is
> the external interface and eth1 is the internal interface.
That's correct.
> If I knew your rule set I would be able to help 100% but going on just
> what you've posted isn't enough to be totally sure this is going to work.
> I use a Cisco VPN client through my firewall without a problem. The key
> is knowing what ports on which protocol is used.
Here's what I've figured out about my problem by using LOG targets and
tcpdump.
Packets go from the internal client to the NAT box and then are
forwarded on to the VPN server fine. They show up in tcpdump coming in
eth1 and out eth0; the iptables LOG targets show SNAT'ing is properly
occurring.
Packets also come from the external VPN server to the NAT box fine.
They show up in tcpdump. They also show up in mangle
PREROUTING--however, they never make it to the nat table. What's even
stranger is that they are properly being
conntracked--/proc/net/ip_conntrack shows an ASSURED connection between
the internal VPN client and the external VPN server. Yet for some
reason that no one yet has been able to figure out, the packets are
silently dropped between mangle and nat.
Because the inbound packets never enter the nat table, I also am unable
to "manually" DNAT them to the internal client. I shouldn't need to do
that anyway, since the packets are properly conntracked.
I've also added match rules to log any invalid packets--nothing shows
up.
The netfilter list discussion starts here:
http://lists.netfilter.org/pipermail/netfilter/2005-November/063703.html
I'm pretty much stumped. Any additional suggestions would be much
appreciated.
Wolfgang Kueter
> [...]
> I'm pretty much stumped.
Actually I'm not surprised. If you read my postings in this thread
carefully again ypu might realize that I told you already several days
ago to terminate the VPN on a public IP. And if you read the IPSeC
protocol specification you might even understand why I told you this. The
VPN endpint can be either your Linux box using e.g. OpenSwan or the
Sonicwall. NAT'ting IPSeC requires NAT traversal and that is definitely
something to avoid especially when setting up a site to site tunnel.
If the Linux Box is the VPN endpoint simply something like
---8<---
# Sample for IPsec Connections
iptables -A INPUT -p udp --sport 500 --dport 500 -j ACCEPT
iptables -A OUTPUT -p udp --sport 500 --dport 500 -j ACCEPT
# we need to allow ESP
iptables -A INPUT -p 50 -j ACCEPT
iptables -A OUTPUT -p 50 -j ACCEPT
# and AH r
iptables -A INPUT -p 51 -j ACCEPT
iptables -A OUTPUT -p 51 -j ACCEPT
---8<---
will do. There is no need to fiddle around with the forward chain when
using the right architecture with the VPN Gateway placed in the
appropriate position.
> Any additional suggestions would be much appreciated.
*Never* termintate an IPSeC (site to site) VPN on a private IP
(10.0.0.0/8, 172.16.0.0./12, 192.168.0.0/16) behind a NAT Gateway or
you'll run into serious problems, always terminate the VPN on a public,
routable IP-address.
Wolfgang
ajke...@gmail.com
IPSec implementation I'm using. This particular SonicWall configuration
does not work with FreeS/WAN or OpenS/WAN. I spent several hours with
one of the OpenS/WAN developers and he was not able to figure it out.
Moreover, corporate policy would prohibit the arrangement you suggest.
When I was using a black box DSL router, the NAT traversal worked fine
with no special configuration. With netfilters, packets are being
dropped in between mangle PREROUTING and nat PREROUTING even though the
connection shows up as tracked under /proc/net/ip_conntrack. My
question is how to debug the packets being dropped when (1) there is no
IPSec on the NAT box (2) they do not show up as INVALID (3) they *do*
show up in mangle PREROUTING but (4) they do not show up in any other
chain or in tcpdump watching the LAN-facing ethernet interface.
Wolfgang Kueter
> Those are not really helpful suggestions.
Terminating an IPSeC Tunnel on a public routable IP thus avoiding NAT
traversal is always a step into right direction. If for whatever reason
you can't follow that general advice it is a pity for you that will often
result in long time to get such a setup running.
> Moreover, corporate policy would prohibit the arrangement you suggest.
Well, actually I'm a bit uncertain about your setup because you never
made clear, so I'll ask to avoid confusion.
Do we have something like
a)
corporate side your side
LanB LanC
LanA---sonicwall---internet---Linux---------sonicwall------PC_2
| |
+---PC_1 +--PC_3
Sample Adresses:
LanA: 192.168.0.0/24
LanB: 192.168.1.0/24
LanC: 192.168.2.0/24
with
Linux eth0 aaa.bbb.ccc.ddd (external, public, routable)
Linux eth1 192.168.1.1
PC_1: 192.168.1.3
sonicwall Gateway: 192.168.1.2 (external, private, non routable)
sonicwall Gateway: 192.168.2.1 (internal, private, non routable)
PC_2: 192.168.2.2
PC_3: 192.168.2.3
and you want the Tunnel to be built by a sonicwall gateway (external
IP assumed to be 192.168.1.2) on your side between the networks
192.168.0.0/24 and 192.168.2.0/24?
OR
b)
Does some computer in your network run some sonicwall VPN client software
and the setup looks like this:
corporate side your side
LanB
LanA---sonicwall---internet---Linux---PC runing sonicwall VPN-client SW
Sample Adresses:
LanA: 192.168.0.0/24
LanB: 192.168.1.0/24
with:
Linux eth0 aaa.bbb.ccc.ddd (external, public, routable)
Linux eth1 192.168.1.1
PC runing sonicwall VPN-client SW: 192.168.1.2
and you want the tunnel to be created between the single PC and the
gateway on the other side?
>
> When I was using a black box DSL router, the NAT traversal worked fine
> with no special configuration. With netfilters, packets are being
> dropped in between mangle PREROUTING and nat PREROUTING even though the
> connection shows up as tracked under /proc/net/ip_conntrack.
Using the mangle table is seldom if ever neccessary and in most cases does
more harm than good.
The first thing what you'll do is to give me details about your setup (I
did already most of your homework, for some ASCII drawings see above).
After that tell me where to send the invoice, give me root access to that
Linux box and approximately 30 minutes, OK, maybe I might need 1 hour.
While setup b will certainly be not much fun setup b will even be
be more difficult ...
hourly rate upon request.
Wolfgang
ajke...@gmail.com
> Does some computer in your network run some sonicwall VPN client software
> and the setup looks like this:
>
> corporate side your side
> LanB
> LanA---sonicwall---internet---Linux---PC runing sonicwall VPN-client SW
That is my set-up, as I indicated in Nov 2, 9:47 am posting. There is
only one Windows client, at a static NAT address, in the LAN behind the
Linux NAT box, that needs to connect with the SonicWall server on the
corporate side.
> Using the mangle table is seldom if ever neccessary and in most cases does
> more harm than good.
I was using the mangle table to log packets, nothing else. I have
established, with tcpdump and a LOG target in the mangle table, that
packets successfully go from the home client to the NAT box on the
Internet, then from the NAT box to the corporate server; and then are
received back from the corporate server to the NAT box, but disappear
somewhere in between mangle PREROUTING and the nat table. They are
never sent out again on the inward facing ethernet interface. I don't
see how logging in the mangle table does "more harm than good."
> While setup b will certainly be not much fun setup b will even be
> be more difficult ...
I'm not sure which setup you mean is more difficult?
> After that tell me where to send the invoice, give me root access to that
> Linux box and approximately 30 minutes, OK, maybe I might need 1 hour.
> hourly rate upon request
I think you're missing the point. I am trying to learn something about
netfilters/iptables and packet routing. If I just wanted a solution, I
would put my Buffalo router back in place because it was working fine.
I posted to this newsgroup and the netfilters email list to try to work
out the problem so I have a better understanding of how this stuff
works and I can help others for free in the future (see, e.g.,
<http://adam.rosi-kessel.org/linux>.)
I've spoken with some very knowledgeable and helpful people who have
helped me isolate the problem to the packets disappearing before they
enter the nat table but haven't been able to figure out why. I'm
hoping to figure out the next step.
Wolfgang Kueter
> I've spoken with some very knowledgeable and helpful people who have
> helped me isolate the problem to the packets disappearing before they
> enter the nat table but haven't been able to figure out why. I'm
> hoping to figure out the next step.
Well, OK, have fun, as long as the sonicwall client does standard NAT-T
(actually I'd not call such crap like NAT-T 'standard') I need about
15 minutes to set that up.
You need a little longer ...
Wolfgang