PF: block between two IP address on same NIC

[dvl@]

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]

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

Regards
Markus

 

[dvl@]

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]

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]

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]

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]

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: [USER=812]@DutchDaemon[/USER] - [USER=1677]@SirDice[/USER]: 1 - 0

 

[dvl@]

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]

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.