Newbee: Port forwarding not working

stephenw10

Yeah what have you setup so far? Posts screenshots so we can review them.

https://docs.netgate.com/pfsense/en/latest/book/nat/port-forwards.html#adding-port-forwards

Steve

bforpc

Hello,

here are the nat & rule screenshot
Bildschirmfoto vom 2020-02-11 08-36-05.png
Hope it helsp.
Everything else are "standard and not changed".

Bfo

Grimeton

@bforpc NAT also heavily relies on routing.Make sure your routing is fine.

bforpc

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

viragomann

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.

Bob.Dig

@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?

bforpc

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.

Bob.Dig

@bforpc Do you try to connect from inside or from outside?
Obviously you do something wrong, but it is hard to guess.

bforpc

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 0

So it looks like, there are requests on pfsense...

Bfo

viragomann

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?

bforpc

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:
Bildschirmfoto vom 2020-02-11 13-24-05.png

Bfo

bforpc

@bforpc

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 interface

Nothing 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

Grimeton

Incoming connections from the outside on the WAN interface are blocked.

Open up the port so that it becomes available.

Cu

Bob.Dig

@bforpc is pfSense directly connected to the internet or what means outside.

stephenw10

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

bforpc

@Bob-Dig
Yes. it is directly connected to the internet (it gets the public ip via dhcp).

bforpc

@Grimeton

How?

bforpc

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