Connection to SonicWall VPN through Linux IPTABLES Firewall/Proxy

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? That will forward all protocols and all ports, right? Or am I misunderstanding something?

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.

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.

Proxy -- e.g.,

"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.

Thanks for your help. Does anyone else have any suggestions?

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.

Am Tue, 01 Nov 2005 08:36:27 -0800 schrieb ajkessel:

You are clueless, having installed something that you don't understand.

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).

iptables is packet filtering, proxy is something else.

Fine, NAT for the net, has nothing to do with VPN.

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

Am Wed, 02 Nov 2005 04:33:18 -0800 schrieb ajkessel:

The filter table is *not* the nat table.

RTFM, man iptables.

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.

Yes, you misunderstand almost everything, even such iptables basics as described at:

Wolfgang

Am Wed, 02 Nov 2005 06:47:32 -0800 schrieb ajkessel:

I just said, that you lack the neccessary knowledge.

This happens on layer 3 (and maybe also 2), a proxy works on layer 4.

Because a proxy works one (or two) layers above.

A proxy is a gateway working on the application layer (layer 4), a router (and also one that does NAT) works below that.

See above.

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*

Those who have unterstood network communication do not mess up these things.

You have no clue about basics in network communication. Therefiore you run into problems and mess everything up.

Obviously you have not.

Because you've messed up everything.

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.

.... or hire a skilled person any pay him.

Wolfgang

Am Wed, 02 Nov 2005 08:26:57 -0800 schrieb ajkessel:

Without the neccessary knowledge you'll not be able t figure that yourself. I told you what to read.

Wolfgang

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

Wolfgang Kueter wrote in news: snipped-for-privacy@shconnect.de:

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.

Without knowing how your rules are setup it would only be a guessing game as to what is wrong.

There are going to be more then this that are causing you your problem.

The above should be like this, you don't need the '-t nat';

iptables -A POSTROUTING -o eth0 -j MASQUERADE

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.

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

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.

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.

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?

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'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.

That's correct.

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:

I'm pretty much stumped. Any additional suggestions would be much appreciated.

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

Those are not really helpful suggestions. I have no choice about the 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.

Am Tue, 22 Nov 2005 16:27:01 -0800 schrieb ajkessel:

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.

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?

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

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.

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."

I'm not sure which setup you mean is more difficult?

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., .)

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.

Am Wed, 23 Nov 2005 08:20:56 -0800 schrieb ajkessel:

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