Port forward not allowing packets through

eiger3970 0

I fixed the port 22 which didn't need port forwarding, just an updated public key.

However I am still unable to VNC into the machine?

These are the steps I processed:
Guide for Ubuntu, Access a remote desktop. https://ubuntu.com/tutorials/access-remote-desktop#1-overview

1: Ubuntu 22.04.3 LTS jammy > Sharing is turned on.

2: VMM 4.0.0 is running VM pfSense port forwarded to 5900 for VNC.
pfSense > Firewall > NAT > Port Forward >
Interface: WAN, Protocol: TCP, Source Address: *, Source Ports: *, Dest. Address: WAN address, Dest. Ports: 5900 (VNC), NAT IP: LAN address, NAT Ports: 5900 (VNC), Description: VNC.

3: I tested the port is forwarded, GRC Shields UP shows 5900 has the status: stealth.

4: I also tested from my phone's RealVNC app with publicWanIP, publicWanIP:3389, publicWanIP:5900 and publicWanIP:5901, but error: The connection attempt timed out.

5: pfSense's Packet Capture on Interfaces WAN and LAN for port 5900 shows no traffic.

6: I ran Ubuntu's GUFW and the report shows: no information about port 22.

tictag

@eiger3970-0 I can't see any issues with your NAT setup but I am struggling to understand your WAN setup. I can't seem to make out a route between your external WAN network (100.76.25.213/10) and your LAN networks. I am assuming that your NIC0/enp3s0 interface has been DHCP assigned by your ISP, and that 100.64.0.1 is your gateway, as opposed to your 'Router (bridged)' device IP address. So where is the route from network 100.76.25.213/10 to vtnet0 /192.168.122.170/24?

I would have expected either:

(1) WAN vtnet0 configured as a virtual switch with just enp3s0 as a member, so vtnet0 picks up your ISP assigned IP OR
(2) enp3s0 is passed through to vtnet0

... either way your pfSense WAN interface has your publicly accessible IP. NAT rules would then be routing and translating between 100.76.25.213/10 and 192.168.1.0/24.

I am no expert at this, I'm barely a novice, so I may well have misunderstood. Please accept my apology if I have.

Also be worth checking whether NAT rules are processed before other firewall rules, maybe a 'higher priority' rule is blocking before NAT allows? Scraping the barrel there.

Also might be worth checking that the firewall in your 'Router (bridged)' device is definitely disabled. I had an old Technicolor router (DWA0120) where the firewall could only be configured as Low, Medium or High so it always blocked unsolicited inbound WAN traffic.

Also, also ... you might want to consider a VPN tunnel to your internal networks rather than opening up TCP port 5900 to the entire world; that's a lot of potential traffic going to some open source software at the heart of your internal network. OpenVPN is dead easy to use, is supported by pfSense and supports split-tunneling, which means that your client devices can choose which traffic to tunnel e.g. VNC traffic, leaving the rest of your device's traffic alone.

I hope this helps.

David.
edit: typo.

tictag

@eiger3970-0

p.s. If memory serves, GRC Shields Up 'stealth' means that it was unable to complete a TCP SYN/ACK handshake, meaning that whilst the port may be open, there is no 'application code' responding to requests. If a port forward rule existed, I believe you would be able to at least complete the TCP handshake.

p.p.s. a far (far) better tool for such network diagnosis is Fyodor's Nmap. There is even a a package available for pfSense but I tend to use it with Kali Linux over a VPN.

eiger3970 0

@tictag 1. Making out a route between the external WAN network (100.76.25.213/10) and the LAN networks is unclear, but the priority is the port forward issue.

Yes, the ISP assigns a DHCP address.
The gateway in 192.168.1.170 on the virtual router. 100.64.0.1 is an IP address that appears during some packet route tests, which I assumed was the bridged router's IP address.
It's confusing, but WAN vtnt0 must have shown packets routing to virbr0?
Yes, pfSense WAN has the public ISP WAN IP address.
Ok, noted that's where the port forwarding takes effect.
There's no access to the ISP's bridged router at 100.64.0.1, so I'm trusting there's no firewall running there.
VPN tunnel sounds interesting. I'll look at OpenVPN.
I'll assume port 5900 is closed, until GRC ShieldsUp shows a green open port. I use nmap, but open source phone apps like a-Shell and LibTerm don't have nmap in their packages as root privilege is needed, so I'll use GRC until I find an app.

$ ip -c a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: enp2s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel master virbr1 state UP group default qlen 1000
    link/ether be:d4:02:23:e3:f3 brd ff:ff:ff:ff:ff:ff permaddr 1c:61:b4:6d:38:4f
3: enp3s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether a8:a1:59:6e:1f:8b brd ff:ff:ff:ff:ff:ff
    inet 100.76.25.213/10 brd 100.127.255.255 scope global dynamic noprefixroute enp3s0
       valid_lft 234sec preferred_lft 234sec
    inet6 2406:2d40:4100:8fb2:d8c5:f69f:19d0:ac81/64 scope global temporary deprecated dynamic 
       valid_lft 260sec preferred_lft 0sec
    inet6 2406:2d40:4100:8fb2:19e6:ab21:d7dc:ccf6/64 scope global dynamic mngtmpaddr noprefixroute 
       valid_lft 260sec preferred_lft 110sec
    inet6 fe80::2920:e7ff:57f9:eec4/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever
4: virbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 52:54:00:ab:7d:3b brd ff:ff:ff:ff:ff:ff
    inet 192.168.122.1/24 brd 192.168.122.255 scope global virbr0
       valid_lft forever preferred_lft forever
5: virbr1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 6e:d4:d7:b2:f2:4b brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.120/24 brd 192.168.1.255 scope global noprefixroute virbr1
       valid_lft forever preferred_lft forever
6: vnet0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master virbr0 state UNKNOWN group default qlen 1000
    link/ether fe:54:00:67:33:86 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::fc54:ff:fe67:3386/64 scope link 
       valid_lft forever preferred_lft forever
7: vnet1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master virbr1 state UNKNOWN group default qlen 1000
    link/ether fe:54:00:1f:45:d9 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::fc54:ff:fe1f:45d9/64 scope link 
       valid_lft forever preferred_lft forever
10: vnet4: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master virbr0 state UNKNOWN group default qlen 1000
    link/ether fe:54:00:66:a3:05 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::fc54:ff:fe66:a305/64 scope link 
       valid_lft forever preferred_lft forever

tictag

@eiger3970-0 said in Port forward not allowing packets through:

Making out a route between the external WAN network (100.76.25.213/10) and the LAN networks is unclear, but the priority is the port forward issue.

The point I was making was that without a route from the external WAN network to your pfSense router, assumed to be interface WAN vtnet0 and assumed to contain your port forwarding rules, external traffic will never appear at this interface to be port forwarded. Remember that a TCP/IP stack will only process packets that are on its own IP network.

For example, two devices on 192.168.1.0/24 and 192.168.2.0/24 cannot talk to each other, even if they were directly connected with a cross-over cable, or plugged into the same hub.

@eiger3970-0 said in Port forward not allowing packets through:

Yes, pfSense WAN has the public ISP WAN IP address.

Unless I am misunderstanding, your pfSense router, assumed to be bound to interface WAN vtnet0 and assumed to contain your port forwarding rules, is on network 192.168.122.170/24, which is a different IP network to 100.76.25.213/10.

I would suggest bridging (or passing through) port enp3s0 to vtnet0 and allow DHCP to assign its IP.

Good luck!

eiger3970 0

@tictag
Thanks, I've installed OpenVPN on pfSense, however seemed to have missed how to export an Inline Configuration?

I followed the guide to install OpenVPN on pfSense KVM router as host and iOS as client.
I'm missing how to export this Inline Conifguration?
I've read:
Installing the OpenVPN Client on iOS and completed this.
OpenVPN Client Export Package > Client Install Package Types > Inline Configurtions, followed this but see no file exported?
Installing the OpenVPN Client on iOS, which says to export the OpenVPN Connect type Inine Configuration file, but how?

During the install of OpenVPN on pfSense KVM router, I have created 3 downloaded files:

ServerCertificate1.crt
ServerCertificate1.key
ServerCertificate1.p12.

I uploaded ServerCertificate1.p12 to my cloud account, accessed the file from the phone, but no options to open in the app OpenVPN?

Gertjan

@eiger3970-0 said in Port forward not allowing packets through:

Installing the OpenVPN Client on iOS and completed this.

You mean : install it and done.
The next step, using this iPhoen app, cna be done only when you've downloaded the opvn config file into the iPhone.

@eiger3970-0 said in Port forward not allowing packets through:

OpenVPN Client Export Package > Client Install Package Types > Inline Configurtions, followed this but see no file exported?

On this page : OpenVPN > Client Export Utility
you should have, for every created client :

Now its just a metter of clicking on

and pfSense proposes you to download a .opvn file with everything included.

This file is a classic opvn file, with the settings, and all the certificates inline. No need to hassle with 4 files. I even presume this is the format you have to use for the OpenVPN iPhone Client app.

As told, mail (I know, bad, but' it is the most simple way) this file you yourself, open the mail on the iPhone. Tap on the included opvn file. The default iPhone mail app permits you to do 'send' the opvn file to the OpenVPN client iPhone app.
Done.

eiger3970 0

@Gertjan Thanks.
I figured out I have to add a user.
I was following the setup guide and this step is not shown.

Remote user on phone now is loaded, but connecting fails, showing error:
Connection Timeout. Connection failed to establish withing given time.

I have port forwarded pfSense to port 1194.
I set the OpenVPN tunnel network on 192.168.2.0/24, which is supposed to be different from my LAN network on 192.168.1.0/24.

It seems strange how the phone doesn't need the public WAN IP address to connect? The phone seems to be connecting as through its within the LAN?
There is nothing in pfSense > VPN > OpenVPN > Clients. Maybe I missed this bit in the setup guide?
I guess my network IP address are wrong somewhere?

eiger3970 0

@eiger3970-0

Port forward pfSense to port 1194 is not needed.
I set the OpenVPN tunnel network on 192.168.2.0/24, which is supposed to be different from my LAN network on 192.168.1.0/24.

It seems strange how the phone doesn't connect to the public WAN IP address? The phone seems to be connecting to 192.168.122.165?
There is nothing in pfSense > VPN > OpenVPN > Clients.

I think I need to add a passthrough from the machine's physical NIC0 to the KVM, so the KVM router pfSense's WAN will be the public WAN IP address. This public WAN IP address will then be automatically populated into OpenVPN's remote access certificate, which I move to the phone for remote access.
Just figuring out how to passthrough on VMM.

tictag

@eiger3970-0 I have never used OpenVPN because I don't allow any access to my internal network from the Internet, I just know that such access is best achieved through a VPN. I can't help you with OpenVPN config.

Regarding passing through the NIC, this is straightforward and explained here. After IOMMU setup, simply add a new PCI Device to your pfSense VM and pick your NIC [port] from the list. After rebooting pfSense, re-run the network configurator and choose the passed-through device as your WAN interface. Note: this directly connects the NIC (port) device to your pfSense VM, it will no longer be available to any other VM - this is usually preferable because everything on the local network should be behind the firewall.

The best way to intuitively understand VPNs is by imagining that the Internet doesn't exist and you have a really long Ethernet cable connecting the external device directly to the internal network i.e. it should pick up an internal IP address from your LAN's DHCP server.

Another point about OpenVPN in particular is that it supports 'split-tunnelling', which means that you can choose which traffic on your external device is routed through the VPN. All traffic is the default option but remember that this will increase latency and use up more of your home network Internet bandwidth. Maybe you only want Remote Desktop type software to route through, or SSH apps?