Block SSH on link-local ipv6 address

yackson

Ok so I have 2 LAN's (LAN1, LAN2) and SSH access to pfsense. I would like to only allow SSH from LAN1. I have added a firewall rule to block it from LAN2 (source: "LAN2 net", destination: "This Firewall") but it only blocks if I try to connect using the firewall's static address on LAN2 interface. I can still SSH into the firewall if I use its link-local IPv6 address. I tried adding some rules with the link-local address as destination but they don't do anything (traffic is still passed). I guess a solution to this problem might be to bind sshd to only one address, the LAN1 address in this case, using the ListenAddress directive. But I can't do that with sshd_config since it gets overwritten by the GUI. So how exactly can I block SSH connections to the link-local address?

johnpoz

Can you post picture of your rules? My guess is the anti-lock out rule is allowing your traffic in, since that allows 22 along with http and https

So I tried to duplicate your issue. So I validated that I could ssh to link local

debug1: Authentication succeeded (publickey).
Authenticated to fe80::250:56ff:fe00:2 ([fe80::250:56ff:fe00:2]:22).

And yup in no problem on link local address. I then undid the antilock out rule. I then put in a rule to block 22 to this firewall on ipv6..

Blocked - see attachment. So lets see the rules you created and on what interface is the traffic coming in on..

sshblockedlinklocal.png_thumb

Gertjan

@johnpoz:

… I then undid the antilock out rule.

This would be
System > Advanced > Admin Access
Anti-lockout => Disable webConfigurator anti-lockout rule
which states :

When this is unchecked, access to the webConfigurator on the LAN interface is always permitted …

By "LAN" pfSense means the FIRST "LAN" interface, or any "LAN and OPTx" interface ?
Right know, I understand that this rule is present on every LAN type interface by default (option not-checked).
Right ?

yackson

Ok, so I changed the source in the block rule from "LAN2 net" to "any" it started working ("LAN2 net" wouldn't work obviously because the link-local address space is not in the LAN2 network). But yesterday I also tried "fe80::/10" as the source and it didn't work. But I just tried it today and it works too ._. Maybe it's because I restarted the machine or something.

Or maybe I didn't actually try SSH yesterday and only tried ping6 which for some reason still gets passed even if protocol is set to "any", so I assumed the same would happen with SSH ??? I don't know…

Here are my LAN2 rules:

Here's what happens when I try SSH using link-local address (it gets blocked, just as expected)


$ ssh -v fe80::215:5dff:fe54:212%eth0
OpenSSH_6.6.1, OpenSSL 1.0.1f 6 Jan 2014
debug1: Reading configuration data /home/morchv/.ssh/config
debug1: /home/morchv/.ssh/config line 6: Applying options for *
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to fe80::215:5dff:fe54:212%eth0 [fe80::215:5dff:fe54:212%eth0] port 22.
(gets stuck here)

And here's what happens when I ping6 the firewall. I would think that the second rule would block it, but it still gets passed:


$ ping6 fe80::215:5dff:fe54:212%eth0
PING fe80::215:5dff:fe54:212%eth0(fe80::215:5dff:fe54:212) 56 data bytes
64 bytes from fe80::215:5dff:fe54:212: icmp_seq=1 ttl=64 time=0.394 ms
64 bytes from fe80::215:5dff:fe54:212: icmp_seq=2 ttl=64 time=0.265 ms
64 bytes from fe80::215:5dff:fe54:212: icmp_seq=3 ttl=64 time=3.72 ms
64 bytes from fe80::215:5dff:fe54:212: icmp_seq=4 ttl=64 time=0.229 ms
^C
--- fe80::215:5dff:fe54:212%eth0 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 2999ms
rtt min/avg/max/mdev = 0.229/1.152/3.722/1.485 ms

I guess I achieved my main goal of blocking SSH, but I still don't quite understand what is happening here. Could someone explain?

Btw, the anti-lockout rule only works on the first LAN afaik, so it shouldn't be affecting things on LAN2, is that correct?

johnpoz

well what is your specific rule - please post it. And show what it actually working if you have rule that should block it.

yackson

It's not that i absolutely NEED to block ALL kinds of communication including ICMP from LAN2 to the firewall. My objective was to block SSH. But i'm just curious why the packets sent by ping are not affected by the firewall rules.

here is the very first rule on LAN2, that should block all connections to the firewall:

here is SSH getting blocked by that rule, looks good:

here is the very last rule on LAN2 used to log everything that is passed

and here is a screenshot of my terminal, confirming SSH is getting blocked and ping is not

no entries related to ping are appearing in the log, for neither of the 2 rules. it's like the packets sent by ping are ignored or something.

johnpoz

Yeah there are rules to allow icmp… look at your rules.debug

IPv6 ICMP is not auxilary, it is required for operation

See man icmp6(4)

1 unreach Destination unreachable

2 toobig Packet too big

128 echoreq Echo service request

129 echorep Echo service reply

133 routersol Router solicitation

134 routeradv Router advertisement

135 neighbrsol Neighbor solicitation

136 neighbradv Neighbor advertisement

pass quick inet6 proto ipv6-icmp from any to any icmp6-type {1,2,135,136} tracker 1000000107 keep state

Allow only bare essential icmpv6 packets (NS, NA, and RA, echoreq, echorep)

pass out quick inet6 proto ipv6-icmp from fe80::/10 to fe80::/10 icmp6-type {129,133,134,135,136} tracker 1000000108 keep state
pass out quick inet6 proto ipv6-icmp from fe80::/10 to ff02::/16 icmp6-type {129,133,134,135,136} tracker 1000000109 keep state
pass in quick inet6 proto ipv6-icmp from fe80::/10 to fe80::/10 icmp6-type {128,133,134,135,136} tracker 1000000110 keep state
pass in quick inet6 proto ipv6-icmp from ff02::/16 to fe80::/10 icmp6-type {128,133,134,135,136} tracker 1000000111 keep state
pass in quick inet6 proto ipv6-icmp from fe80::/10 to ff02::/16 icmp6-type {128,133,134,135,136} tracker 1000000112 keep state

Which would explain why that is not blocked.

Which is why it would be kind of nice to see all the hidden rules in the gui maybe with an advanced toggle or something.

yackson

Alright, that makes sense. Thanks for the help.