PF No SSH When WAN Interface Down

[smdb01us]

Howdy,

I am scratching my head a bit here, hoping someone can suggest or help me explain this. I have an Intel mini computer (Beelink) with two interfaces (igc), one facing the Internet provider (igc0 DHCP) and the other my local network (igc1). When both interfaces are up and running, I can SSH with no issues but when the Internet facing interface is down or I have no IP address (ISP issue), I get a rejected connection from the internal IP address when I try to SSH. I can't see any rules on SSH what would block me from connecting but based on the mesaage that I get from SecureCRT, I think this is lower level reject, not SSH (nothing on the SSH logs as well). My ruleset for pf is very basic:

block log all
pass in on $lan from $lan:network to any
pass out on $wan from ($wan) to any
pass in on $lan proto udp from port = 68 to port = 67
pass out on $lan proto icmp from 192.168.1.1 to $lan:network

Any ideas why pf would reject my connection? As I am typing this, I am thinking that I did not check my pglog so I will do it now, while I, hopefully, get some of y'all chime in on theories why this is happening.

Thank you!

 

[mer]

Howdy,

I am scratching my head a bit here, hoping someone can suggest or help me explain this. I have an Intel mini computer (Beelink) with two interfaces (igc), one facing the Internet provider (igc0 DHCP) and the other my local network (igc1). When both interfaces are up and running, I can SSH with no issues but when the Internet facing interface is down or I have no IP address (ISP issue), I get a rejected connection from the internal IP address when I try to SSH. I can't see any rules on SSH what would block me from connecting but based on the mesaage that I get from SecureCRT, I think this is lower level reject, not SSH (nothing on the SSH logs as well). My ruleset for pf is very basic:

block log all
pass in on $lan from $lan:network to any
pass out on $wan from ($wan) to any
pass in on $lan proto udp from port = 68 to port = 67
pass out on $lan proto icmp from 192.168.1.1 to $lan:network

Any ideas why pf would reject my connection? As I am typing this, I am thinking that I did not check my pglog so I will do it now, while I, hopefully, get some of y'all chime in on theories why this is happening.

Thank you!

I assume you mean ssh from one host on igc1 (local interface) to another host on igc1?
Are you using raw ip addresses or names (DNS lookup)?
Do you have any specific configuration for the target in .ssh/config?
Have you increased the debug level, "ssh -vvv"? If so what does that say?

Asking because in theory, if you are using IP addresses and are going local IP to local IP there should be no requirement on igc0 (WAN). But that's why the question about "by IP or by name"

 

[smdb01us]

I assume you mean ssh from one host on igc1 (local interface) to another host on igc1?
Are you using raw ip addresses or names (DNS lookup)?
Do you have any specific configuration for the target in .ssh/config?
Have you increased the debug level, "ssh -vvv"? If so what does that say?

Asking because in theory, if you are using IP addresses and are going local IP to local IP there should be no requirement on igc0 (WAN). But that's why the question about "by IP or by name"

Sorry, I meant trying to connect from a local IP address (laptop, desktop computer, etc) to the igc1 ip address. I only use IP addresses, no names at all. The ip address of igc1 (internal) is pingable during this time. This is why I think it is weird to me. Compounding the problem, I managed to disable the HDMI/console access so, I was flying bling this morning when my IPS was having issues... lol.

 

[JordanG]

If you want to debug a network problem, you will speed up the process tremendously if you observe the packets that go through the network interfaces. Programs like tcpdump or Wireshark can help you do that.

Some more suggestions:

• Unplug the Internet cable to bring the igc0 interface down and disable pf. Verify whether there is a problem. If there isn't, the problem comes from pf.
• Try to connect with nc(1) or telnet(1) to the ssh port (port 22). See if you will receive the server banner. If the connection attempt is successful, you should look for the problem in ssh/sshd.

 

[smdb01us]

If you want to debug a network problem, you will speed up the process tremendously if you observe the packets that go through the network interfaces. Programs like tcpdump or Wireshark can help you do that.

Some more suggestions:

• Unplug the Internet cable to bring the igc0 interface down and disable pf. Verify whether there is a problem. If there isn't, the problem comes from pf.
• Try to connect with nc(1) or telnet(1) to the ssh port (port 22). See if you will receive the server banner. If the connection attempt is successful, you should look for the problem in ssh/sshd.

Thank you JordanG. I am planning to do testing after work but I am going to leave a connection open to the box before I unplug my Internet interface. I was not able to troubleshoot because I could not log in to the my box at all until the Internet came back up.

 

[sko]

I can't see any rules on SSH what would block me from connecting but based on the mesaage that I get from SecureCRT, I think this is lower level reject, not SSH (nothing on the SSH logs as well).

No idea what SecureCRT is, but there might be clues if you crank up the verbosity level ( ssh -v).

Wild guess: you don't run a local DNS resolver and UseDNS is enabled in sshd_config(5), leading to a timeout for logins when there is no uplink available. (You should see the timeout when trying to connect via ssh -v)