PF: block between two IP address on same NIC

dvl@

Aspiring Daemon
Developer

Reaction score: 63
Messages: 550

Can pf block between IP addresses that are on the same NIC?

Code:
# ifconfig | grep 10.5.0.16
	inet 10.5.0.160 netmask 0xffffffff broadcast 10.5.0.160
	inet 10.5.0.161 netmask 0xffffffff broadcast 10.5.0.161
The goal: stop SSH on 10.5.0.160 to 10.5.0.161

Code:
# pfctl -sr 
No ALTQ support in kernel
ALTQ related functions disabled
scrub in all fragment reassemble
block drop quick inet from 10.5.0.160 to 10.5.0.161
pass in all flags S/SA keep state
pass out all flags S/SA keep state
I ask because:

Code:
$ ifconfig | grep inet
	inet 10.5.0.160 netmask 0xffffffff broadcast 10.5.0.160
$ ssh 10.5.0.161
dan@10.5.0.161's password:
i.e. it does not seem to work as expected.
 

storvi_net

Active Member

Reaction score: 25
Messages: 133

Is the last line just a typo? The IP there is 10.55.0.161...

Regards
Markus
 
OP
OP
dvl@

dvl@

Aspiring Daemon
Developer

Reaction score: 63
Messages: 550

storvi_net said:
Is the last line just a typo? The IP there is 10.55.0.161...

Regards
Markus
Well spotted. Yes, that was a typo. Now corrected.

Thank you.
 

DutchDaemon

Administrator
Staff member
Administrator
Moderator
Developer

Reaction score: 2,773
Messages: 11,279

You might have to tackle lo0 for this. It might be where the traffic actually flows through, and most people routinely set it to skip.

Example:

Ping from xxx.yyy.169.74 to xxx.yyy.169.78, both on the same NIC:

Code:
$ ping xxx.yyy.169.78
PING xxx.yyy.169.78 (xxx.yyy.169.78): 56 data bytes
64 bytes from xxx.yyy.169.78: icmp_seq=0 ttl=64 time=0.036 ms
64 bytes from xxx.yyy.169.78: icmp_seq=1 ttl=64 time=0.024 ms
Code:
# tcpdump -s 0 -pnli lo0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on lo0, link-type NULL (BSD loopback), capture size 65535 bytes

17:53:41.569056 IP 127.0.0.1 > xxx.yyy.169.78: ICMP echo request, id 35390, seq 0, length 64
17:53:41.569070 IP xxx.yyy.169.78 > 127.0.0.1: ICMP echo reply, id 35390, seq 0, length 64
17:53:42.569346 IP 127.0.0.1 > xxx.yyy.169.78: ICMP echo request, id 35390, seq 1, length 64
17:53:42.569355 IP xxx.yyy.169.78 > 127.0.0.1: ICMP echo reply, id 35390, seq 1, length 64
 

SirDice

Administrator
Staff member
Administrator
Moderator

Reaction score: 7,181
Messages: 29,471

dvl@ said:
Can pf block between IP addresses that are on the same NIC?
I don't think that's possible because the traffic doesn't pass through the interface.
 

storvi_net

Active Member

Reaction score: 25
Messages: 133

Is this not quite often neccessary to do this in a jails environment? I think the OP wants to forbid the Inter-Jail-Communication.

Is it normal, that all jails can communicate with each other?

Regards
Markus
 

J65nko

Well-Known Member

Reaction score: 127
Messages: 453

Environment: one NIC and sshd LISTENing on all interfaces.

Code:
# ifconfig bge0 | grep inet
        inet 192.168.222.240 netmask 0xffffff00 broadcast 192.168.222.255
        inet 192.168.222.241 netmask 0xffffffff broadcast 192.168.222.241

# netstat -an -f inet
Active Internet connections (including servers)
Proto Recv-Q Send-Q Local Address          Foreign Address        (state)
tcp4       0      0 *.22                   *.*                    LISTEN

# cat /etc/pf.conf
EXT_IF = bge0

#set skip on lo0
block log all
pass in quick on $EXT_IF inet proto tcp from ! $EXT_IF to $EXT_IF port ssh


# pfctl -vvf /etc/pf.conf
No ALTQ support in kernel
ALTQ related functions disabled
Loaded 700 passive OS fingerprints
EXT_IF = "bge0"
@0 block drop log all
pass in quick on bge0 inet proto tcp from ! 192.168.222.240 to 192.168.222.240 port = ssh flags S/SA keep state
pass in quick on bge0 inet proto tcp from ! 192.168.222.240 to 192.168.222.241 port = ssh flags S/SA keep state
pass in quick on bge0 inet proto tcp from ! 192.168.222.241 to 192.168.222.240 port = ssh flags S/SA keep state
pass in quick on bge0 inet proto tcp from ! 192.168.222.241 to 192.168.222.241 port = ssh flags S/SA keep state
Check whether any skip rules are in effect:
Code:
# pfctl -vs Interfaces
No ALTQ support in kernel
ALTQ related functions disabled
all
bge0
lo
lo0
lo1
pflog
pflog0
usbus0
usbus1
No skipped interfaces and the logins fail:

Code:
# ssh 192.168.222.240
ssh: connect to host 192.168.222.240 port 22: Operation not permitted
# ssh 192.168.222.241
ssh: connect to host 192.168.222.241 port 22: Operation not permitted
Flush the rules, enable the skip, reload and retry the ssh attempts:

Code:
# pfctl -F all
No ALTQ support in kernel
ALTQ related functions disabled
rules cleared
nat cleared
0 tables deleted.
0 states cleared
source tracking entries cleared
pf: statistics cleared
pf: interface flags reset

# vi /etc/pf.conf

# pfctl -vvf /etc/pf.conf
No ALTQ support in kernel
ALTQ related functions disabled
Loaded 700 passive OS fingerprints
EXT_IF = "bge0"
set skip on { lo0 }
@0 block drop log all
pass in quick on bge0 inet proto tcp from ! 192.168.222.240 to 192.168.222.240 port = ssh flags S/SA keep state
pass in quick on bge0 inet proto tcp from ! 192.168.222.240 to 192.168.222.241 port = ssh flags S/SA keep state
pass in quick on bge0 inet proto tcp from ! 192.168.222.241 to 192.168.222.240 port = ssh flags S/SA keep state
pass in quick on bge0 inet proto tcp from ! 192.168.222.241 to 192.168.222.241 port = ssh flags S/SA keep state

# pfctl -vs Interfaces

No ALTQ support in kernel
ALTQ related functions disabled
all
bge0
lo
lo0 (skip)
lo1
pflog
pflog0
usbus0
usbus1
With the loopback skip enabled we can login:
Code:
# ssh 192.168.222.240
The authenticity of host '192.168.222.240 (192.168.222.240)' can't be established.
ECDSA key fingerprint is c0:8c:10:32:8d:ab:1c:99:3c:9f:5d:67:31:33:96:f8.
Are you sure you want to continue connecting (yes/no)? no
Host key verification failed.

# ssh 192.168.222.241
The authenticity of host '192.168.222.241 (192.168.222.241)' can't be established.
ECDSA key fingerprint is c0:8c:10:32:8d:ab:1c:99:3c:9f:5d:67:31:33:96:f8.
Are you sure you want to continue connecting (yes/no)? no
Host key verification failed.
Conclusion: @DutchDaemon - @SirDice: 1 - 0 ;)
 
Last edited by a moderator:
OP
OP
dvl@

dvl@

Aspiring Daemon
Developer

Reaction score: 63
Messages: 550

DutchDaemon said:
You might have to tackle lo0 for this. It might be where the traffic actually flows through, and most people routinely set it to skip.
Indeed. My simple test on lo0 was successful.

Let the rule writing begin....
 

mlager

Member


Messages: 54

Great thread, I spun my wheels on this same issue all night. Who would have thunk to look at that lo0 interface that's just sitting down there in ifconfig all these years.
 
Top