Re: Connection to SonicWall VPN through Linux IPTABLES Firewall/Proxy

I've actually moved this conversation over to the netfilters list,
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.
Received on Sat Dec 3 04:17:36 2005