How to setup and use 1:1 NAT

[aaronouthier]

Hello,
I just switched from PFSense to OpnSense, since my aging APU1D4 isn't going to be supported after the next update to PFSense.

Here is the situation: I live in a house with 3 other people, and I setup my router behind the ISP's router in a Double-NAT configuration. This is mostly for privacy - I don't want opportunistic room mates using my printer, etc.

I DO have one device that I need to expose to the outer network, however. I posted on the forum for that device, to ask what ports need to be forwarded, and they informed me that the device needs to be on the same subnet as the computer that is interfacing with it. Basically, I have a network TV Tuner, that needs to be on 2 different networks at the same time, but without the Tuner knowing about the other network. If I understand correctly, I need to setup 1:1 NAT, on a virtual IP address on the WAN. I am going crazy trying to get it going, however!

So, my ISP router has a DHCP server issuing leases on the 192.168.254.0/24 subnet. Inside of that, I have my OpnSense router with a Static IP address of 192.168.254.252 and a 24-bit netmask. Gateway 192.168.254.254, which is the IP of the ISP's router. I have confirmed that 254.252 is outside of the ISP's router's DHCP Pool.

My TV Tuner is on IP address 192.168.1.2, and is behind my OpnSense Firewall. I created a Virtual IP address of 192.168.254.253 on the WAN address of the OpnSense router, and am trying to cause all traffic intended for 192.168.254.253 to forward transparently to 192.168.1.2, kind of like what is referred to as a DMZ on other routers.

Am I even going about this the correct way? Thus far, I have been unable to connect to the embedded Web Server on the TV Tuner from any machine on the 254.0/24 subnet by opening a browser and pointing it to '192.168.1.253' with my previous efforts. Then again, I've never before tried to setup a 1:1 NAT mapping before, and I'm not exactly familiar with how it works, which makes it all the more daunting.

Some insight here would help.

--Aaron

P.S.: I've searched the forums to see if my question was already answered, but I only found a bunch of vague questions, with 0 replies.

[franco]

Hi there,

It should be the same as on pfSense, you set a WAN VIP and set 1:1 mapping (firewall: NAT: One to one).

https://docs.netgate.com/pfsense/en/latest/nat/1-1-nat.html

We are still working on our docs coverage, the chapter for 1:1 is still missing because good documentation exists.  ;)

https://docs.opnsense.org/


Cheers,
Franco

[aaronouthier]

Ok. Weird. I already had it configured properly. For some reason, it didn't start working until I cleared out my browser history and cookies, etc.

I can now access the web server across subnets.

As it turns out, however, I need to relay broadcast packets on a particular port from one network to the other. I found a program that should help, but I am having trouble compiling it.

The program is found on Github at:
https://github.com/nomeata/udp-broadcast-relay

I am thinking I should start a new topic for this, as it is now a new problem.

[aaronouthier]

Update: udp-broadcast-relay doesn't compile properly on FreeBSD/PFSense/OpnSense. I managed to get the updated fork, udp-broadcast-relay-redux, working properly. It turns out, however, that it isn't enough - I need to relay TCP packets also.

Does anyone here know enough about firewall syntax to translate iptables rules to pf rules?
I found that iptables under linux by itself may be sufficient, but I don't know if it is possible to get this to work under OPNSense. I've looked at the WebUI, but I don't think I'd be able to implement this there.

Code Select Expand

iptables -t mangle -A INPUT -i eth0 -d 255.255.255.255 -m ttl --ttl-gt 0 -j TTL --ttl-set 1
iptables -t mangle -A INPUT -i eth1 -d 255.255.255.255 -m ttl --ttl-gt 0 -j TTL --ttl-set 1
iptables -t mangle -A INPUT -i eth0 -d 255.255.255.255 -m ttl --ttl-gt 0 -j TEE --gateway 10.1.1.255
iptables -t mangle -A INPUT -i eth1 -d 255.255.255.255 -m ttl --ttl-gt 0 -j TEE --gateway 10.1.0.255

[newsense]

...aging APU1D4...

Not aging, but arguably out of date. Chec out the Hardware subforum in the APU 1-5 thread on how to get the latest firmware on it - securely. Pages 5-6.

pfSense is not requiring AES-NI for 2.5 - unsure whether the API was the major factor though...

The original plan was to include a RESTCONF API in pfSense 2.5.0, which for security reasons would have required hardware AES-NI or equivalent support. Plans have since changed, and pfSense 2.5.0 does not contain the planned RESTCONF API, thus pfSense 2.5.0 will not require AES-NI.

https://forum.netgate.com/topic/140586/heads-up-snapshots-moving-to-pfsense-2-5-0-on-freebsd-12-expect-initial-instability


Have you looked into Avahi at all ? Might be the solution you're looking for while voiding all those stray packages that will likely be difficult to maintain given OPNsense's rather aggresive patching cycle.

[franco]

How unfortunate. And here we are still waiting for pfSense 3.0 since OPNsense started while 2.5 features and promises get axed. This is not a rant, I want to show you how little direction pfSense has had for a long time.

https://www.netgate.com/blog/further-a-roadmap-for-pfsense.html

> we will be removing all of the PHP from the system. Yes, all of it.

So where's that, in a Linux non-open-sourced product. ;)

> the WebGUI will be re-written to leverage this REST API.

See Not-in-2.5 department.

We have not yet finished API conversion, but we have quite a few of them in core features and plugins:

https://docs.opnsense.org/development/api.html?highlight=api

> More automated testing can be performed.

https://github.com/pfsense/UI-Automated-Testing

Look at all the testing since "Updated on 2 Feb 2018": This repository is empty.

> Second, the package system from FreeBSD will be brought fully to bear. The ideal here is that "pfSense" is, itself, a package on top of FreeBSD.

You can cleanly install and remove OPNsense from FreeBSD since November 2015:

https://github.com/opnsense/update#opnsense-bootstrap

I'm not aware pfSense can do this yet.

> Third, the core of pfSense (pf, packet forwarding, shaping, link bonding/sharing, IPsec, etc) will be re-written using Intel's DPDK.

It was, now not available in open source nor in FreeBSD so not for pfSense as of yet. ;)

Meanwhile we have Suricata + Netmap which gets frequent updates and Sensei, a NGFW plugin for OPNsense based on the same Netmap idea. DPDK is better than Netmap for throughput, but it's an OEM vendor battlefield that you can only win by investing in licensing prewritten modules or writing your own and try to compete...

> And finally, pfSense will move to use even more advanced encryption techniques for IPsec, TLS and OpenVPN.

Unless you don't have an API and shift the requirement for AESNI back....

> Finally, since I mentioned OpenSSL, let me say this: Other projects may explore alternative implementations of OpenSSL (e.g. LibreSSL), but pfSense is unlikely to do this for three reasons

Who cares what you don't do. Choice is good. We provide LibreSSL as an official alternative since 2015 and sponsor compatibility patches in HardenedBSD and sometimes FreeBSD. Everybody wins. :)


Cheers,
Franco

[newsense]

Thanks for that, it's...quite unfortunate. I was aware of the completely inappropriate .com issue and the lousy 'stick with OpenSSL 'cause I trust a guy' justification.

While I never looked into their development model much, the rather slow release cycle ond occasional patches were a growing concern from a security appliance point of view - otherwise simply from the FreeBSD's perspective pf would work just fine anywhere for a simplet set of rules.


My only headache so far in many months with OPN has been the recent unbound/DoT mess ongoing since 18.7.10 but I'll wait for 19.1.2 update which hopefully will be ready soon to see if the HBSD related issues persist.

[franco]

Try Unbound 1.9 on 19.1.2 and up to see if it gets better... DoT and DoH have been a pretty mess for both upstream servers and Unbound so far -- two of the reasons why we have been reluctant in shipping GUI helpers for their configuration.


Cheers,
Franco