Setting up a Windows VPN through a Fedora Linux gateway

Hi,

After a Google search I could only find information relevant to
kernels 2.2 and older (using ipchains and ipfwdadm). I can't
seem to find out the way to translate that info to iptables
syntax and rules.

Anyway, the setup that I have is:

Linux machine:
dual NIC. eth0 connected to the Internet, to a Cable-TV ISP using
DHCP.
eth1 configured as 192.168.0.1 and connected (through a switch) to
my home network

The machine where I'm sitting now is currently on Windows 2000,
with static IP address 192.168.0.2, and I need to connect to a
remote server via VPN. I did the setup, but when I try to connect,
I get a "Could not connect - no response" error message.

From the information I've seen, it looks like I have to do some
port redirection (or port forwarding?), such that whatever packets
the gateway receives to certain ports are forwarded to 192.168.0.2

I assume not all ports -- only the ones used by the VPN protocol.

Am I understanding correctly? If yes, what would be the required
iptables statement on my gateway machine?

This is the iptables script that I'm using right now (called from
/etc/rc.local):

iptables -t nat -F
iptables -t mangle -F
iptables -t filter -F

iptables -F INPUT
iptables -F OUTPUT
iptables -F FORWARD

iptables -Z INPUT
iptables -Z OUTPUT
iptables -Z FORWARD

iptables -X

iptables -P INPUT DROP
iptables -P OUTPUT ACCEPT
iptables -P FORWARD DROP

iptables -A INPUT -i eth1 -j ACCEPT
iptables -A INPUT -m state --state INVALID -j DROP
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

## Do not allow ANYTHING related to MS networking
iptables -A FORWARD -i eth1 -p tcp --dport 137:139 -j REJECT
iptables -A FORWARD -p tcp --dport 137:139 -j DROP
iptables -A FORWARD -i eth1 -p udp --dport 137:139 -j REJECT
iptables -A FORWARD -p udp --dport 137:139 -j DROP

iptables -A FORWARD -i eth1 -j ACCEPT
iptables -A FORWARD -m state --state INVALID -j DROP
iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

echo "1" > /proc/sys/net/ipv4/ip_forward


I'll be most grateful for any help or pointers!

Thanks,

Carlos
--

On Thu, 26 May 2005 16:02:53 -0400, Carlos Moreno
<(E-Mail Removed)> wrote:


> From the information I've seen, it looks like I have to do some
>port redirection (or port forwarding?), such that whatever packets
>the gateway receives to certain ports are forwarded to 192.168.0.2

I don't think so. I've got a similar setup where I vpn into my office
network from home. The windows vpn is a client, there should be no
need for port forwarding at the client end. The problems I had were
at the firewall at the office, the server end.

But you can prove it for yourself using ethereal and/or tcpdump. You
can monitor three interfaces, eth0 and eth1 on the linux box, and the
interface on the windows box. Then you can see what packets are going
out and you can make sure they're getting through your firewall. And
you can see if any packets are coming back and how far they get.

Dan

Dan wrote:

>>From the information I've seen, it looks like I have to do some
>>port redirection (or port forwarding?), such that whatever packets
>>the gateway receives to certain ports are forwarded to 192.168.0.2
>
>
> I don't think so. I've got a similar setup where I vpn into my office
> network from home. The windows vpn is a client, there should be no
> need for port forwarding at the client end. The problems I had were
> at the firewall at the office, the server end.

Huh... I initially thought that should be the case -- pretty much like
my web browser works, and reading e-mail works, etc., I assumed that
a VPN client would also work.

But then, when seeing that it wouldn't work, and after completely
turning off ZoneAlarm, I figured that it might be a case where the
server initiates a connection to the client machine in response to
the incoming connection (to prevent IP spoofing or similar reasons,
perhaps)

> But you can prove it for yourself using ethereal and/or tcpdump. You
> can monitor three interfaces, eth0 and eth1 on the linux box, and the
> interface on the windows box. Then you can see what packets are going
> out and you can make sure they're getting through your firewall. And
> you can see if any packets are coming back and how far they get.

I don't doubt the packets are passing through the firewall on their
way out -- hmmm, unless ports 137, 138, or 139 are used? (I completely
blocked those, under the assumption that only NetBIOS would use them)

Perhaps I should double check on the server end, to see if they have
some specific restrictions on how to connect.

Thanks,

Carlos
--

On Thu, 26 May 2005 22:11:03 -0400, Carlos Moreno
<(E-Mail Removed)> wrote:


>Huh... I initially thought that should be the case -- pretty much like
>my web browser works, and reading e-mail works, etc., I assumed that
>a VPN client would also work.

Yes.

I don't remember all the details, it was quite some time ago that I
set it up, but the firewall at my end wasn't the problem. I've since
changed the firewall, now use shorewall, and did absolutely nothing in
terms of setting up for a vpn.

The place where I had the problem was the remote firewall. Not only
did I have to open and forward a port, but had to also let through a
gre protocol (sorry, I've forgotten any details.)

If you set up ethereal/tcpdump, you can see if you're getting anything
back at all. Maybe the gre protocol is were the problem is. If you
have a hardware router at the far end, it will have to be one that
lets through a vpn. ( I think that means that it lets through gre.)
If the firewall is a linux box, then you have to configure netfilter
for gre as well.

Dan