Newbee: Port forwarding not working
-
@bforpc NAT also heavily relies on routing.Make sure your routing is fine.
-
Hi Grimeton,
im a newbee with pfsense. So what and where i setup this correctly to access a server from Internet over pfsense in my intranet?
Bfo
-
The NAT and firewall rules seem to be okay.
Ensure that the destination device responses to SSH access from the internet.
You may use the Packet Capture tool from the Diagnostic menu to investigate. Take a capture on the LAN while you try SSH from WAN to see if packets are natted as expected and if you get responses from that device. -
@bforpc said in Newbee: Port forwarding not working:
192.168.1.1
And sure that your linux machine is 192.168.1.1 and not pfSense? How is your network setup?
-
Yes im absolute sure about the ip adresses.
The hole intranet is working for long time with ipfire and access via ssh to 192.168.1.1 (this is the VM Host). Ipfire is off and out. pfsense has 192.168.1.101/24 as lan interface. -
@bforpc Do you try to connect from inside or from outside?
Obviously you do something wrong, but it is hard to guess.
-
of corse, I trying from outside :-)
Packet capture show me this (in this test i use wan:1022 to Lan:22)12:56:05.508511 IP [public ip client].60954 > [public ip pfsense].1022: tcp 0 12:56:05.508667 IP [public ip pfsense].1022 > [public ip client].60954: tcp 0 12:56:06.242282 IP [public ip pfsense].1022 > [public ip client].60950: tcp 0 12:56:06.523324 IP [public ip client].60954 > [public ip pfsense].1022: tcp 0 12:56:06.523411 IP [public ip pfsense].1022 > [public ip client].60954: tcp 0 12:56:07.554284 IP [public ip pfsense].1022 > [public ip client].60954: tcp 0So it looks like, there are requests on pfsense...
Bfo
-
So pfSense sends out responses back to the client again. Seems everything is fine so far and your problem is not due to pfSense.
What's the output on the client when trying to connect? -
This is the output at the internet client
ssh -v -p1022 [public ip of pfsense] OpenSSH_7.9p1 Debian-10+deb10u2, OpenSSL 1.1.1d 10 Sep 2019 debug1: Reading configuration data /root/.ssh/config debug1: Reading configuration data /etc/ssh/ssh_config debug1: /etc/ssh/ssh_config line 19: Applying options for * debug1: Connecting to [public ip pfsense] port 1022.and thats it ...
From pfsense i test the port:
Bfo
-
additional info:
If i run on 192.168.1.1 tcpdump and simultaneously try ssh from outside to pfsense:
~:tcpdump -i vmbr0 "src host 192.168.1.101" and "dst port 22"tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on vmbr0, link-type EN10MB (Ethernet), capture size 262144 bytes ^C 0 packets captured 1 packet received by filter 0 packets dropped by kernel 1 packet dropped by interfaceNothing is comming from pfsense.
So it must be a pfsense conffiguration, in detail, it must be a blocking rule.
But where?
And again: Pfsense is right from scratch installed. Only IP Assigments to the interfaces.
I think, my question is not more then an absoltly basic thing!?bfo
-
Incoming connections from the outside on the WAN interface are blocked.
Open up the port so that it becomes available.
Cu
-
@bforpc is pfSense directly connected to the internet or what means outside.
-
The source will still be the external public IP you're testing from if you pcap on the target host. Not the pfSense LAN IP.
I would not expect to see any traffic there.Try doing the port test to 192.168.1.1 in pfSense but set the source IP to the WAN address.
The target should still show as open. If it does not then the target is refusing connections from outside it's subnet. That may have worked previously if IPFire was source NATing the traffic as it left the LAN.
Steve
-
@Bob-Dig
Yes. it is directly connected to the internet (it gets the public ip via dhcp). -
How?
-
I found the Problem:
At the proxmox hosting platform, there was an option, to pass the traffic through the Host firewall (what was disabled).
Therefore - pfsense has done everything right. After disabling this flag everything works like expected.THX for your support!!!
Bfo
