Greetings,
> Check your pf rules carefully. And check your routing/bridging config
> carefully, this setup with loads of veb and whatever vports certainly
> makes things more complicated. Do you actually need it, what are you
> trying to achieve with it? Simplify if you can. As far as I'm concerned
> ridging on pf boxes would be a special case that I'd try to avoid unless
> there's no alternative.
Here is my complete pf.conf:
# $OpenBSD: pf.conf,v 1.55 2017/12/03 20:40:04 sthen Exp $
#
# See pf.conf(5) and /etc/examples/pf.conf
set skip on lo
block return # block stateless traffic
pass # establish keep-state
# By default, do not permit remote connections to X11
block return in on ! lo0 proto tcp to port 6000:6010
# Port build user does not need network
block return out log proto {tcp udp} user _pbuild
match out log on em1 from 10/8 to any nat-to 104.167.241.211
It's basically just the default pf.conf with that rule added to the end
(I removed any dynamic lookups as you suggested).
Here is the complete routing table if it helps:
Routing tables
Internet:
Destination Gateway Flags Refs Use Mtu Prio Iface
default 104.167.241.193 UGS 11 5198051 - 8 em1
224/4 127.0.0.1 URS 0 193 32768 8 lo0
10/8 10.2.1.1 UGS 0 1201 - 8 vport11
10.1/16 10.1.2.1 UCn 0 0 - 4 vport11
10.1.2.1 fe:e1:ba:dc:65:83 UHLl 0 940 - 1 vport11
10.1.255.255 10.1.2.1 UHb 0 0 - 1 vport11
10.2.1.1 e8:8b:21:21:21:21 UHLch 1 2250 - 7 vport11
10.2.1.1 link#154 UHCS 1 0 - 8 vport11
104.167.241.192/26 104.167.241.211 UCn 1 1532666 - 4 em1
104.167.241.48/29 104.167.241.49 UCn 6 63 - 4 vport0
104.167.241.48 link#11 UHLc 0 115 - 3 vport0
104.167.241.49 fe:e1:ba:d0:b5:eb UHLl 0 557652 - 1 vport0
104.167.241.50 e8:8b:27:7b:7a:00 UHLc 0 1780557 - 3 vport0
104.167.241.51 link#11 UHRLc 0 101 - 3 vport0
104.167.241.52 link#11 UHLc 0 109 - 3 vport0
104.167.241.53 link#11 UHLc 0 162 - 3 vport0
104.167.241.54 e8:8b:27:7b:7a:01 UHLc 0 2466471 - 3 vport0
104.167.241.55 104.167.241.49 UHb 0 127949 - 1 vport0
104.167.241.193 ac:1f:6b:fe:ca:98 UHLch 2 783055 - 3 em1
104.167.241.211 00:25:90:5a:2d:92 UHLl 0 842125 - 1 em1
104.167.241.255 104.167.241.211 UHb 0 484601 - 1 em1
127/8 127.0.0.1 UGRS 0 0 32768 8 lo0
127.0.0.1 127.0.0.1 UHhl 2 1839573 32768 1 lo0
> Standard PF diagnosis tools are to add "log" to various rules, or add
> "match log(matches)" to the top of the ruleset, and tcpdump -nei pflog0,
> but N.B. due to a bug in (iirc) 7.3 to 7.5 the rule numbers printed by
> tcpdump will be wrong if you have any anchors in the ruleset - that's
> fixed in -current.
When I run $ ping 1.1.1.1 on R2, I run this tcpdump on the host and I
see the packet matching:
host# tcpdump -ne -i pflog0 'host 1.1.1.1'
tcpdump: WARNING: snaplen raised from 116 to 160
tcpdump: listening on pflog0, link-type PFLOG
13:05:33.555191 rule 5/(match) match out on em1: 10.2.1.1 > 1.1.1.1: icmp: echo request
^C
1 packets received by filter
0 packets dropped by kernel
But when I run ping 1.1.1.1 on R5, I run tcpdump on the host and I don't
see any matches:
host# tcpdump -ne -i pflog0 'host 1.1.1.1'
tcpdump: WARNING: snaplen raised from 116 to 160
tcpdump: listening on pflog0, link-type PFLOG
^C
0 packets received by filter
0 packets dropped by kernel
When I run tcpdump on the em1 interface instead of on pflog0, I see R5's
pings matching:
host# tcpdump -ne -i em1 'host 1.1.1.1'
tcpdump: listening on em1, link-type EN10MB
13:06:02.019325 00:25:90:5a:2d:92 ac:1f:6b:fe:ca:98 0800 98: 10.5.3.1 > 1.1.1.1: icmp: echo request
13:06:03.019307 00:25:90:5a:2d:92 ac:1f:6b:fe:ca:98 0800 98: 10.5.3.1 > 1.1.1.1: icmp: echo request
^C
The hardware addresses are also correct, that's the hardware address
from the host's em1 interface to the default gateway. So the packets are
being sent, but NAT is not being performed, and I have no idea why.
--
jrmu
IRCNow (https://ircnow.org)
No comments:
Post a Comment