TightVNC behind FreeBSD 11.0 Natd

T

Tom Frontera

I use FreeBSD 11.0 for a Gateway to the internet. On the local network I run win7 machines with TightVNC - so I can remotely mange them. But I can not get through to the local machines from the outside world. Not sure if it is the natd or ipfw.

The server rc.conf file is:
Code: 
hostname="gate.mydomain.com"
defaultrouter="189.199.69.193"
ifconfig_re0="inet 189.199.69.241 netmask 255.255.255.192"
ifconfig_dc0=" inet 192.168.10.1 netmask 255.255.255.0"
gateway_enable="YES"
natd_enable="YES"
natd_interface="re0"
natd_flags="-f /etc/natd.conf"
firewall_enable="YES"
firewall_type="OPEN"
firewall_script="/etc/ipfw.rules"
sshd_enable="YES"
ntpd_enable="YES"
named_enable="YES"
sendmail_enable="NO"
dhcpd_enable="YES"
dhcpd_ifaces="dc0"
bsnmpd_enable="YES"
sshd_enable="YES"
Then my natd.conf is:
Code: 
interface re0
use_sockets yes
same_ports yes
dynamic yes

redirect_port tcp 192.168.10.116:5900 5900
redirect_port udp 192.168.10.116:5900 5900

I have tried this various ways but the natd port forwarding does not seem to work. I have commented out the firewall_script="/etc/ipfw.rules" line in the rc.conf to see if it is the ipfw rules - but still doesn't work.

Is their something new in 11.0 that is preventing the natd forwarding? This same setup is working fine on my 10.3 box.

Any help would be appreciated.
 
Last edited by a moderator:
The firewall must allow traffic on tcp/udp 5900.

natd(8) won't work without a proper ipfw(8) ruleset. As a matter of fact your ipfw ruleset must contain a natd divert rule at a proper place. Also note that since a long time, ipfw got a native (built-in) nat, whose syntax is very similar to the natd syntax.

A basic stateful NAT'ing ipfw(8) setup using the native NAT looks as follows:
Code: 
#!/bin/sh
WAN="re0"
LAN="dc0"

/sbin/ipfw -q flush
/sbin/ipfw -q table all flush
/sbin/ipfw -q nat 1 config if $WAN unreg_only\
                                   reset\
                                   redirect_port tcp 192.168.10.116:5900 5900\
                                   redirect_port udp 192.168.10.116:5900 5900

# Allow anything within the LAN - interface with heaviest traffic shall come first.
/sbin/ipfw -q add 10 allow ip from any to any via $LAN
/sbin/ipfw -q add 20 allow ip from any to any via lo0

# Catch spoofing from outside.
/sbin/ipfw -q add 70 deny ip from any to any not antispoof via $WAN

# NAT rule for incoming packets - IPv4 only, IPv6 ain't work with NAT.
/sbin/ipfw -q add 100 nat 1 ip4 from any to any in recv $WAN
/sbin/ipfw -q add 101 check-state

# Rules for outgoing traffic - allow everything that is not explicitely denied.
/sbin/ipfw -q add 1000 deny ip from not me to any 25,53 out xmit $WAN
/sbin/ipfw -q add 1001 deny ip from any to any 5353 out xmit $WAN

# Allow all other outgoing connections, i.e. skip processing to the outbound NAT rule #10000
/sbin/ipfw -q add 2000 skipto 10000 tcp from any to any out xmit $WAN setup keep-state
/sbin/ipfw -q add 2001 skipto 10000 udp from any to any out xmit $WAN keep-state

# Rules for incomming traffic - deny everything that is not explicitely allowed.
/sbin/ipfw -q add 5000 allow tcp from any to me 22,25,80,587,993,995 in recv $WAN setup keep-state
/sbin/ipfw -q add 5001 allow udp from any to me 500,4500 in recv $WAN keep-state

# Rules for allowing packets to services which are listening on a LAN interface behind the NAT
/sbin/ipfw -q add 6000 skipto 10000 tcp from any to any 5900 in recv $WAN setup keep-state
/sbin/ipfw -q add 6001 skipto 10000 udp from any to any 5900 in recv $WAN keep-state

# Catch any other tcp/udp packet, but don't touch gre, esp, icmp, etc...
/sbin/ipfw -q add 9998 deny tcp from any to any via $WAN
/sbin/ipfw -q add 9999 deny udp from any to any via $WAN

# NAT rule for outgoing packets.
/sbin/ipfw -q add 10000 nat 1 ip4 from any to any out xmit $WAN

# Allow anything else - just in case ipfw is not configured as open firewall.
/sbin/ipfw -q add 65534 allow ip from any to any
 
Thank You - I will test this out. If the port redirection is now part of ipfw rules do I need the port redirects in natd.conf?
 
Tom Frontera said:
Thank You - I will test this out. If the port redirection is now part of ipfw rules do I need the port redirects in natd.conf?
Click to expand...

No, you don't need to configure and activate natd(8). Let's assume, you place the ruleset that has bee given in my previous massage into the file /etc/ipfw.conf. In this case you would put into /etc/rc.conf the following, ...:
Code: 
...
# Firewall & NAT
gateway_enable="YES"
firewall_enable="YES"
firewall_nat_enable="YES"
firewall_script="/etc/ipfw.conf"
...
... and all the other firewall_ and the natd_ directives should be removed.

PS:
The file ipfw.conf is actually a shell script and it should be made executable -- owner root:wheel:

# chown root:wheel /etc/ipfw.conf
# chmod +x /etc/ipfw.conf
 
ok - I was able to get ipfw_nat working instead of natd..... I added ipfw_nat_load="YES" to /boot/loader.conf and disabled natd options in rc.conf. But the port redirection is still being blocked by ipfw with the example ipfw rules above. Seems like people are switching to pf because of this change. I want to use ipfw, but I'm at a loss right now. Also when I try to add to kernel I get this:
/usr/src/sys/amd64/conf/G01UV: unknown option "IPFW_NAT"
*** Error code 1

I did have to alter ipfw rule #1000 and remove port 53 to get my dns working on the local network workstations:
/sbin/ipfw -q add 1000 deny ip from not me to any 25 out xmit $WAN

I must be missing something very basic becuase I'm sure many people are using port redirection with ipfw.
 
I forgot two tiny details:
  • Packages in a NAT'ting ruleset may/shall be processed more than once, and by default there is a short circuit sysctl variable active that prevents this. So please add to the file /etc/sysctl.conf the following:
    Code: 
    ...
net.inet.ip.fw.one_pass=0
  • The ipfw/NAT does not play well with TCP segmentation offloading. Please add to the parameters of your ifconfig_xx0 directives in /etc/rc.conf the flag -tso.
 
I strongly advise not to open VNC to the big bad internet. It's going to bite you sooner or later (it's a common way for bad people to get in). I would recommend using SSH to login on the firewall and use SSH tunneling to tunnel VNC.
 
SirDice said:
I would recommend using SSH to login on the firewall and use SSH tunneling to tunnel VNC.
Click to expand...

Does anyone know of tools to allow this to function on an iPad? There are some excellent VNC apps on iOS, but that OS is so locked down I have no idea how to go about setting up an SSH tunnel.
 
I have no idea for iOS but on my Android phone I use ConnectBot. It's a SSH client that also allows to create secure tunnels. It works good enough to tunnel VNC or RDP over it. I'm sure there are similar apps for iOS.
 
I use ConnectBot on my Android phone as well, great app. Hopefully I can find something like it for iOS. (I despise iOS but have to admit that Safari with ad blocking is a much better browsing experience than anything I can find on Android, so the iPad sticks around...)
 
IMHO, L2TP/IPsec-VPN is the way to go for iOS and macOS. The intergrated VPN clients in the operating systems from Apple work perfectly together with the VPN server on my FreeBSD home server that I have set up using security/strongswan + net/mpd5.

I can dial-in to my home network via VPN and then can access everything as if I were at home. The clients are set to let everything go over the VPN and by this way roadrunner clients benefit as well from the firewall and the anti spam settings on the gateway.
 
You must log in or register to reply here.
Back
Top