Re: Still can't use ADSL, PF problem

From: clvrmnky (clvrmnky-uunet_at_coldmail.com.invalid)
Date: 08/24/04


Date: Tue, 24 Aug 2004 14:41:49 -0400

On 23/08/2004 2:51 PM, Johnathan Doe wrote:

>>I second the advice to look at the FAQ examples and build your ruleset
>>up from there. The examples reflect real-world use.
>
>
> Didn't work for me for some reason. I used the FAQ examples, and Googled
> and found at least five other examples. None of them worked. I also tried
> everything with two different ADSL modems.
>
> I must be doing something seriously wrong that's obvious to everyone else
> but not to me...
>
Weird. It really should just work. I think maybe you are blocking all
traffic on all devices.

Try a very bare-bones pf.conf that ignores traffic to/from anything
other than your external device. You mention PPP as your external
connection, so the external device is probably tun0. Substitute as
necessary for what you really have.

[...]
# $Id: pf.conf,v 1.3 2004/01/26 05:01:19 root Exp $
# Define useful variables
ExtIF="tun0" # External Interface

# by default, block all incoming packets, except those explicitly
# allowed by further rules
block in on $ExtIF all

# pass in specific service request here, if you like

# let out-going traffic out on the external interface
pass out on $ExtIF all keep state
# Alternatively, you can specify exact protocol specifics:
#block out on $ExtIF all
#pass out on $ExtIF inet proto tcp all flags S/SA modulate state
#pass out on $ExtIF inet proto udp all keep state
#pass out on $ExtIF inet proto icmp all keep state
#pass out on $ExtIF inet proto gre all keep state
[...]

I also often use a very simple set of rules that I use to rule out
filter problems when testing the external network connectivity:

[...]
pass in all
pass out all
[...]

Either of these should allow all kinds of connections to be established
from this router host. For this to work from arbitrary hosts within
your network, you will have to define a set of NATing rules.

e.g.:
[...]
# $Id: nat.conf,v 1.5 2004/01/26 05:02:37 root Exp $
# macros
ExtIF="tun0" # External Interface
ExtIP="xx.yy.aa.bb" # External IP
IntNet="10.0.0.0/8" # Internal network

# NAT all outgoing traffic
nat on $ExtIF from $IntNet to any -> $ExtIP
[...]

Apply the rules sets in this manner:

sudo pfctl -e -Fa -R /etc/pf.conf -N /etc/nat.conf

You can remove the "-e" option once pfctl is active, or ignore the
messsage it causes.

Remember to move from the known to the unknown. You cannot solve
problems higher up unless things have been resolved lower down.

- Are all the required net devices "up"? Can PPP dial out and establish
a tunnel? Does this tunnel have an IP address? ifconfig -a is your
friend here. If PPP cannot establish a connection, then nothing else
will work.

BTW, I do not bring up the filter until _after_ ppp has dialed out and
made a tunnel. I use ppp.linkup to run "/sbin/pfctl -Fa -R /etc/pf.conf
-N /etc/nat.conf". However, I've never had a problem reestablishing a
dropped connection automatically with PF active afterwards.

- Check the routing table via netstat. Is traffic not destined for your
internal network set to the tunnel by default? Does "ping" and
"traceroute" to external routeable addresses work?

Remember that ICMP stuff like ping may not work as you expect over PF
unless care is taken in your ruleset (note my optional protocol lines in
the example, above.)

- Do higher-level communications like DNS work? Can you resolve and
reverse lookup external sites?



Relevant Pages

  • Re: Secret Underground.
    ... There is no intentional connection* from the GWR running tunnel into ... the quarries. ... connection, which is one reason why the quarry surveys are so accurate... ... The easternmost shaft is at a point where the tunnel roof is close to ...
    (uk.rec.subterranea)
  • Re: Secret Underground.
    ... There is no intentional connection* from the GWR running tunnel into ... connection, which is one reason why the quarry surveys are so accurate... ... The easternmost shaft is at a point where the tunnel roof is close to the level of the workings, so that one's unlikely but not impossible. ... There wouldn't be any need either: when the munitions store was planned and in use, exit through any of the western quarries was easily possible. ...
    (uk.rec.subterranea)
  • Re: Somewhat OT -- Looking for ideas on how to test status of SSH TCP tunnel
    ... > I am planning on setting up a TCP tunnel through an SSH connection ... > This tunnel will be used to provide a connection between a Perforce ... > The OS for Korean proxy server will be Redhat FC3 using OpenSSH. ...
    (Fedora)
  • Somewhat OT -- Looking for ideas on how to test status of SSH TCP tunnel
    ... I am planning on setting up a TCP tunnel through an SSH connection ... tunnel will be used to provide a connection between a Perforce Proxy ... server in Korea and our main Perforce server in the US. ...
    (Fedora)
  • Re: Somewhat OT -- Looking for ideas on how to test status of SSH TCP tunnel
    ... > I am planning on setting up a TCP tunnel through an SSH connection between ... > The OS for Korean proxy server will be Redhat FC3 using OpenSSH. ...
    (Fedora)