Hi,
I am experiencing some problems with pf: On one of my ethernet ports
UID/PID is not working (on the others it does work). Therefore UID based
rules do not work on that port.
Details:
On my firewall (PC engines board) there are 4 ethernet ports: 3 physical
(vc0, vc1 and vc3) and 1 tunnel (tun0). The tunnel device goes (using
openvpn) to a few vmware machines.
Trying to find the problem I did the following:
I added 1 rule as the first rule.
pass out quick log (user) proto tcp to port 54321
Then I logged in as user 1000 and ran the command:
telnet <adres> 54321
This causes the following logging
21:42:23.159427 rule 1/(match) [uid 0, pid 15934] pass out on vr0: [uid
1000, pid 5202] 10.0.1.1.47296 > 10.0.1.2.54321 ...
21:42:40.799061 rule 1/(match) [uid 0, pid 15934] pass out on vr1: [uid
1000, pid 17378] 172.16.1.1.34300 > 172.16.1.2.54321 ...
21:42:49.041844 rule 1/(match) [uid 0, pid 15934] pass out on tun0: [uid
1000, pid 30058] 172.16.2.1.13800 > 172.16.2.2.54321...
21:42:58.635498 rule 1/(match) [uid 0, pid 15934] pass out on vr2:
83.117.153.61.57591 > 12.16.2.2.54321 ...
As can be seen only the vr2 interface does not show UID/PID. Note that
the first UID/PID is not the one of interest here, that UID/PID
represents the process that inserted the rule.
In an attempt to find the cause I looked at the differences between vr2
and the other interfaces:
- vr2 has an alias (it has 2 addresses). I removed it and rebooted, no
difference
- vr2 has a dynamically assigned address. I did not test this as most
interfaces have this.
- vr2 shows in its ifconfig 'groups: egress'. I have no idea what this
is or how it is caused, therefore I was unable to test whether changing
it has impact.
- vr2 has 'block drop all' whereas the others have 'block policy return'
I did not test this as most interfaces have this.
In addition I:
- Removed the tun0 device to check whether it was causing the problem.
No difference.
- Ported the firewall to vmware using dump restore and some editing of
the configuration files to accommodate the different type of ethernet
ports etc. It runs perfectly but has the very same symptoms. Therefore
it not probable that the problem is caused by the network drivers.
I am out of ideas about what might be causing this. Can anybody help.
--
Peter
