Last Friday I upgraded a host to core 196.
Seemed to go well. However, I find that the rules using port forwarding are no longer working. I can no longer ssh to the servers.
I’ve tried recreating one of the rules to no avail. I also tried restoring from a backup before the issue, but that did not help either..
On the client:
ssh: connect to host ip_address_removed port 22222: Connection refused
On fire wall side in messages I see this:
Jul 28 10:47:11 ipfire kernel: INPUTFW IN=red0 OUT= MAC=00:1f:29:57:75:02:54:39:68:19:e0:27:08:00 SRC=ip_address_removed DST=ip_address_removed LEN=60 TOS=0x08 PREC=0x20 TTL=51 ID=54125 DF PROTO=TCP SPT=46380 DPT=22222 WINDOW=64240 RES=0x00 SYN URGP=0
Source address: Ip I’m connecting from
Nat Use nat > Destination NAT
Destination: ip of server trying to connect to.
Protocal: TCP > Destination port 22 > External Port (NAT) 22222
Activate rule checked
Rule position 1 (Moved it up just for grins to see if would help)
Nothing was changed in the CU196 update related to the firewall rules.
On my vm network, I have a range of ssh firewall rules to test accessing the ssh servers on clients and the ssh server on the IPFire vm itself.
All of those ssh connections are working without any problem since my CU196 update.
Your best bet is to add -v or -vv or -vvv to you ssh command to give you increased verbosity. -v or -vv is best to start with as -vvv is very verbose.
The increased verbosity should give you some indication of at which stage the problem is occurring.
You should also look at the ssh logs at the end you are trying to connect to to see if anything is getting through at all or is completely blocked, although as you have the INPUTFW chain forwarding the access, it suggests that your ssh traffic is getting through and you need to get more information on why the connection was refused by the server you were trying to connect to.
Just to confirm, your ssh port on the server is 22222
More info:
Can connect to firewall by enabling ssh using key.
Can connect to gui on firewall by using a rule… to allow from the same IP I’m trying to connect from.
Just saw your reply with this entry. So I also tried it with one of my vm clients where I have destination port 22 and external port 23, similar to your setup but with different numbers.
Connection worked fine.
I think there is some issue at the server not accepting connection.\
As suggested increase the verbosity and see where the connection gets refused by the server.
-v did not help, but I’d actually forgotten that. Thanks
What did help was removing and recreating the rule to access the firewall, then recreating the other rules. Things starting working as soon as I deleted the rule to access the firewall itself remotely. I don’t remember how I had that rule exactly, but I’m convinced it was interfering with the other rules. Been like that for at least 6 months though and worked.. In any regard, thanks for the fast responses that helped me put on my thinking cap!
In any regard, thanks for the fast responses that helped me put on my thinking cap!