On Sun, Apr 14, 2024 at 04:33:58PM +0200, Karel Lucas wrote:
> Output from "tcpdump -neti pflog0":
> tcpdump: WARNING: snaplen raised from 116 to 160
> tcpdump: listening on pflog0, link-type PFLOG
> ...
> rule 4/(match) pass in on igc1: 192.168.2.252 > 17.253.53.207: icmp: echo
> request
> ...
>
> output from "pfctl -sr -R 4":
> pass log inet proto icmp all icmp-type echoreq
CAVEAT: I assume that 17.253.53.207 is NOT the address of igc0, and that
you are trying to ping a host on the internet. If this is not true
(i.e. if you are pinging the internet-facing IP if your firewall), some
of what I write below won't apply.
So you sent an ICMP ping (an 'Echo request', or echoreq, for short) to
17.253.53.207, which was allowed to enter via igc1. It matched rule 4
which allows ICMP echoreqs on an interfaces (regardless of source or
destination).
Now there are three questions:
1. Did the firewall forward the echoreq to 17.253.53.207, via icg0?
2. Did 17.253.53.207 send an "echo reply" (or "echorep") in response to
your request?
3. Did the firewall let that reply enter igc0, and did it forward it
to 192.168.2.252, via igc1?
You don't show any logs for it, but I think we can stop at question 1,
and the answer to that is: no. You are not NATing your outgoing traffic
for the internet. Without NAT, the package that should leave via igc0
will leave igc0 have 192.168.2.252 as its source address (you should
see something like "pass out on igc0: 192.168.2.252 > 17.253.53.207 ..."
on tcpdump. Even if it's not filtered along the way, the host a
17.252.53.207 will want to send the "echo reply" to 192.168.2.252. But
since this is an address reserved for private use, it won't be routed
across the internet and back to your network (of which only the IPv4
address on igc0 will be 'visible').
So, in short, you need to add a "nat-to rule". You can find examples of
this on the pf.conf man page. But I would advise you to pick up Peter
Hansteen's The Book of pf and give it a good read (at least the first
few chapters).
Now note that even with NATting, you still might not get a reply, since
the remote host might choose to ignore it (question 2, above) and,
crucially, even if it does, you don't have "echorep" on yout $icmp_types
macro. Which means you allow for ICMP echo requests, but not for the
echo replies to them (question 3, above).
To better debug this, you might want to add two more tcpdumps, to see
what goes out and comes in at each interface:
tcpdump -nti igc0 icmp
tcpdump -nti igc1 icmp
It then becomes easier to see where along the way the traffic is being
dropped.
>
> Op 12-04-2024 om 19:46 schreef Zé Loff:
> > On Fri, Apr 12, 2024 at 07:04:16PM +0200, Karel Lucas wrote:
> > > Hi all,
> > >
> > > Traceroute still won't work. I'm playing around with the rules and
> > > wondering
> > > what's right and what's wrong with the traceroute rules. Can anyone give
> > > me
> > > some starting points here?
> > >
> > >
> > > /etc/pf.conf:
> > >
> > > ext_if = igc0 # Extern interface
> > > int_if = "{ igc1, igc2 }" # Intern interfaces
> > > localnet = "192.168.2.0/24"
> > > tcp_services = "{ smtp, domain, www, auth, http, https, pop3, pop3s }"
> > > udp_services = "{ domain, ntp }"
> > > email = "{ smtp, imap, imaps, imap3, pop3, pop3s }"
> > > icmp_types = "{ echoreq, unreach }"
> > > icmp6_types = "{ echoreq, unreach }"
> > > nameservers = "{ 195.121.1.34, 195.121.1.66 }"
> > > client_out = "{ ssh, domain, pop3, auth, nportntp, http, https, \
> > > 446, cvspserver, 2628, 5999, 8000, 8080 }"
> > > Martians = "{ 127.0.0.0/8, 192.168.0.0/16, 172.16.0.0/12, \
> > > 10.0.0.0/8, 169.254, 0.0/16, 192.0.2.0/24, \
> > > 0.0.0.0/8, 240.0.0.0/4 }"
> > >
> > > set skip on lo
> > > # By default, do not permit remote connections to X11
> > > block return in on ! lo0 proto tcp to port 6000:6010
> > >
> > > block log all # block stateless traffic
> > >
> > > block in quick on $ext_if from $martians to any
> > > block out quick on $ext_if from any to $martians
> > >
> > > # Letting ping through:
> > > pass log on inet proto icmp icmp-type $icmp_types
> > > pass log on inet6 proto icmp6 icmp6-type $icmp6_types
> > >
> > > # Allow out the default range for traceroute(*):
> > > # "base+nhops*nqueries-1" (3434+64*3-1)
> > > pass in on $ext_if inet proto udp to port 33433:33626 # for IPv4
> > > pass log out on $ext_if inet proto udp to port 33433:33626 # for IPv4
> > > pass in on $ext_if inet6 proto udp to port 33433:33626 # for IPv6
> > > pass log out on $ext_if inet6 proto udp to port 33433:33626 # for IPv6
> > >
> > Your final four rules (for traceroute) only apply to the $ext_if, so I
> > am assuming you are trying to traceroute _from_ the firewall itself to
> > some machine on the internet. If you want to start traceroute from
> > your local network, and to a machine on the internet, you'll need to
> > add $int_if to those rules (and perhaps NAT, but let's not get ahead of
> > ourselves).
> >
> > Again, assuming you are trying to traceroute from the firewall to the
> > internet, I would use tcpdump to check if that traffic is being blocker,
> > and, if so, which rule is blocking it:
> >
> > tcpdump -neti pflog0
> >
> > (-n and -t are optional, but help to keep thing simpler in this case)
> >
> > Then on another terminal try to traceroute an easily identifiable IP,
> > such as 1.1.1.1, and see what comes up on the tcpdump. It'll be
> > something like "rule 2/(match) block ..." or "rule 2/(match) pass ...",
> > and if you don't want to count the rules by hand, you can use pfctl to
> > tell you which:
> >
> > pfctl -sr -R <id>
> >
> > where <id> is the rule number.
> >
> > Then, assuming it is being blocked, its time to figure out why the
> > "pass" rules aren't being matched.
> >
> >
>
--
