Re: vpn-forwaring
On 24/09/10 12:51, Sthu Deus wrote:
Good day.
Which modules I should insmod in order to make working a vpn forwarding
on a firewall from a local host (a M$ machine) to a outer host (the vpn
server)?
I have rules in iptables like this:
-A FORWARD -p tcp -s 192.168.0.0/24 –dport 1723 -d
VPN_SERVER_IP -j ACCEPT
You also need the same forwarding for the GRE tunnel (IP protocol 47)
(the conntrack modules just record links between protocols, they don't
add forwarding by themselves):
-A FORWARD -p 47 -s 192.168.0.0/24 -d VPN_SERVER_IP -j ACCEPT
Now I need to load something like
ip_nat_pptp
ip_conntrack_proto_gre
ip_conntrack_pptp
But I found not ether of them in Debian 5 stable. So, what should I do
for the forwarding?
Good question. I suspect if you install iptables, Debian will add the
common conntrack modules by itself, and some may now be built into the
core netfilter code. I'm fairly sure I don't have any explicit
configuration, but lsmod shows nf_conntrack and a number of other nf_
and iptables related modules installed. Add the GRE forwarding first,
and see if that works.
Have you checked whether the VPN works without a firewall in between?
The PPTP VPN has a large number of variables, and it is worth knowing
for sure that the client and server talk together before you try
debugging the firewall, especially if they are different operating
systems. Conversely, if you have VPN troubles later, an iptables
firewall with logging rules added in both directions is an excellent
troubleshooting tool.
If you aren't familiar with the MS PPTP VPN, the first contact is made
using TCP/1723, over which the GRE encryption negotiation occurs. The
first data sent through the tunnel is the user authentication handshake,
so if the user is seeing a claim that the VPN is connected but then
there is a timeout after a failure to authenticate, this is a sign that
TCP/1723 is OK, but GRE is not.
By the way, if you connect VPNs between different sites, watch the IP
network address, which must be different for all client-server pairs.
The 192.168.0., 192.168.1. and 192.168.16. networks are in very common
use, and you might want to avoid them.
--
Joe
Reply to: