windows VPN pptp through RH 7.1 ipchains firewall

Posted on 2004-10-10
Medium Priority
Last Modified: 2013-12-06
Okay so I have searched the internet and the EE site for this and I applied many solutions that I have found here to no avail.  I have XP SP 1a and rh 7.1 as a gateway/router on my home network.It has two eth.  eth1 is linnked to the ppp0 from the RP client.  eth0 is on my 192 network.  According to everything I have read I should only need to add 4 ipchains to my rc.local to allow the VPN to work.  So part of of my question is:  Is this correct I have seen note that mention using modprobe ip_masq_pptp to make this work ( Thgis commend does not work on my system modprobe cannot find module).  So assuming question ones answer is no I don't need anything else, then what should the Ipchains  line look like??

Mine look like so ( these are just the VPN line as my firewall is dirt simple)  

ipchains -A input   -i eth1  -p tcp  -d 123.345.678.876 --dport 1723 -j ACCEPT

ipchains -A input   -i eth1  -p 47  -d 123.345.678.876 -j ACCEPT

ipchains -A output -i eth1 -p tcp -d 123.456.678.987 --dport 1723 -J ACCEPT

ipchains -A ouput   -i eth1  -p 47  -d 123.345.678.876 -j ACCEPT

When I run TCP dump the releveant error is as follows

eth1> PPPoE  12.123.345.456> : icmp: protocol 47 unreachable (DF)

whcihc tells me I have a bad setup or I am missing something  Any help is appreciated
Question by:Darnest
  • 5
  • 4

Expert Comment

ID: 12293182
The VPN interface is not eth1 (even though physically that may seem to be the case), it's ppp0.  Your firewall rules should concern ppp0 instead.

Author Comment

ID: 12294907
have actually tried it with ppp0 with the same results.  The 47 protocol (GRE) is unreachable.  I thought it should be ppp0, but ot was late and that was the last setting I had used.  I retried this just to be sure and the VPN seens to find the system, but the login fails.  Any other ideas really appreciated.

Expert Comment

ID: 12296974
Well DF I think stands for "don't fragment", which probably refers to your MTU.  Do a search on MTU pppoe linux vpn or something and that will most likely tell you how to set it correctly... you need it at 1492 if I recall correctly.

I would open up the firewall completely for the purposes of your tests.  Then you can narrow down whether it's a firewall rule problem or something else.

Ahhh wait... what are you trying to do?  Which machine is the client and which machine is the server in this connection?  Are you just trying to pass the VPN packets through your firewall?
Managing Security & Risk at the Speed of Business

Gartner Research VP, Neil McDonald & AlgoSec CTO, Prof. Avishai Wool, discuss the business-driven approach to automated security policy management, its benefits and how to align security policy management with business processes to address today's security challenges.


Author Comment

ID: 12299134
Yes that is exactly what I want to do.  Win XP is the client with a 192.168.x.x,  Linux red hat 7.1 is the firewall and gateway192.168.10.x (eth0) and 67.X.X.X(ppp0),  VPN server is out in NJ.  I will try flushing all the chains and just running the IPchains MASQ and see what Happens.  I may have tried that before, but i may have not flushed all the chains when I did it , So I will try again.  Other than that this seems like it should be simple, setup the protocol and open the port to a specific machine and all should work.  I found this on the internet in an old post.  I have not tried it yet doe sthis look like something should even try???

ipchains -A input -p tcp -i $extint -s $anywhere -d $vpnserver 1723 -j ACCEPT
ipmasqadm portfw -a -P tcp -L $extnet 1723 -R $vpnserver 1723 /mnt/floppy/ipfwd --masq $vpnserver 47 &

it all just looks like different ways of saying what I have doen already...

Thanx for the input I really appreciate it.

Accepted Solution

fletchgqc earned 1500 total points
ID: 12307124
Well, I use SUSE 9.0 and i've never used ipchains, only iptables.  However it looks pretty similar.  I do exactly what you are trying to do on my own network.

If I were you I would forget about opening ports.  Just say that any connection originating within your network should be allowed.  This will cover VPN.  Here are the relevant lines of my firewall file - this works for me.  You may have to modify it for ipchains (?)

# Configure default policies (-P), meaning default rule to apply if no
# more specific rule below is applicable.  These rules apply if a more specific rule below
# is not applicable.  Defaults are to DROP anything sent to firewall or internal
# network, permit anything going out.

iptables -P INPUT DROP
iptables -P FORWARD DROP

# Flush (-F) all specific rules
iptables -F INPUT
iptables -F FORWARD
iptables -F OUTPUT
iptables -F -t nat

# The rest of this file contains specific rules that are applied in the order
# listed.  If none applies, then the above policy rules are used.

### Connections originating internally ###
# Forward all packets from eth0 (internal network) to ppp0 (the internet).
iptables -A FORWARD -i eth0 -o ppp0 -j ACCEPT

# Forward packets that are part of existing and related connections from ppp0 to eth0.
iptables -A FORWARD -i ppp0 -o eth0 -m state --state ESTABLISHED,RELATED -j ACCEPT

# Note, in the above two rules, a connection becomes ESTABLISHED in the
# iptables PREROUTING chain upon receipt of a SYNACK packet that is a
# response to a previously sent SYN packet. The SYNACK packet itself is
# considered to be part of the established connection, so no special
# rule is needed to allow the SYNACK packet itself.

# Masquerade local network
iptables -A POSTROUTING -t nat -o ppp0 -j MASQUERADE

# Allow all inputs to firewall from the internal network and local interfaces
iptables -A INPUT -i eth0 -s 0/0 -d 0/0 -j ACCEPT
iptables -A INPUT -i lo -s 0/0 -d 0/0 -j ACCEPT

# Permit packets in to firewall itself that are part of existing and related connections.
iptables -A INPUT -i ppp0 -m state --state ESTABLISHED,RELATED -j ACCEPT

# DNS queries:
# We need to permit querying a remote DNS server... and dnscache makes requests
# for DNS lookups to external DNS servers, those servers send back responses via UDP to
# the high numbered client port to connect back to dnscache.
iptables -A INPUT -p udp -s 0/0 --source-port 53 -d 0/0 --destination-port 1024:65535 -j ACCEPT


Author Comment

ID: 12309274
I will try this tonite.  I am pretty sure that rh 7.1 has IPtables so I will just switch over.  One question is after I flush all the IPChains out do I need to stop IP chains or does it not matter.  I will let you know if this works.   Thanx A bunch

Author Comment

ID: 12317014
okay,  I cannot run IPtables every time i to run insmod it says the module is busy.  So it is obvious I have other issues here.  Any way Tried to create an ipchains that matches the above..  The issue I have is that  in IPchains the only way I can find to even work with the Sync packets is with the -y  flag on the tcp protocol. and this simply allows or denys them.  Based on the above  ipchains text the reason your VPN woeks is because the synack is part of the established connection due to the Establishe,related commands.  I cannot find anything which matches that in ipchains.  So I think I need IP tables to get this working.  thoughts???

So when I run insmod - p it says I have kernel 2.4.2-2 and that the iptables Device or resource is busy.  So where do I get the newest IP tables  rpm to install that or can some one tell me how to make IPchains do the established,related stuff???

Thanx also since I am at rh 7.1 would upgrade to 7.2 work???  I cannot run 9.0 as my machine is not beefy enough.  I think we are close thanx for the help in advance.


Author Comment

ID: 12320947
Also one morenote.  I think the issue is with my kernel.  I turned off all input and output rules and setup a forward with a masq only.  That means (from what I understand) that it should take everything no if ands or buts and masq between my gateway PC and the loacl network.  I still get the protocool 47 unreachable.  which means to me that perhapse the kernel cannot  do something with the GRE packets and as such they get lost.

anybody have any ideas if rh 7.2 would fix this???


Expert Comment

ID: 12345390
Yes with these rules (or ipchains equivalent) it should mean "no firewall"

iptables -P INPUT ACCEPT

# Flush (-F) all specific rules
iptables -F INPUT
iptables -F FORWARD
iptables -F OUTPUT
iptables -F -t nat

Anyway are you sure the connection works without your firewall?  I don't know anything else if you can't get it working without the firewall rules in there.

Maybe you got it working as I see you accepted my answer?

Featured Post

The new generation of project management tools

With monday.com’s project management tool, you can see what everyone on your team is working in a single glance. Its intuitive dashboards are customizable, so you can create systems that work for you.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

If you’re involved with your company’s wide area network (WAN), you’ve probably heard about SD-WANs. They’re the “boy wonder” of networking, ostensibly allowing companies to replace expensive MPLS lines with low-cost Internet access. But, are they …
Make the most of your online learning experience.
In this brief tutorial Pawel from AdRem Software explains how you can quickly find out which services are running on your network, or what are the IP addresses of servers responsible for each service. Software used is freeware NetCrunch Tools (https…
Monitoring a network: how to monitor network services and why? Michael Kulchisky, MCSE, MCSA, MCP, VTSP, VSP, CCSP outlines the philosophy behind service monitoring and why a handshake validation is critical in network monitoring. Software utilized …

593 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question