Can (and do) I use iptables to expose a host directly online (not using NAT)?

Question

I'm using a DSL-5300 VDSL modem/router which is set up with NAT for my house, and works great. Its web interface hasn't been written to support a mix of NAT and no-NAT traffic.

I've been assigned 8 public IP addresses. I've set up a linux box on one of these IPs, and wired it (eth0) to my the modem.

Logging in as root to my modem and using TCPDUMP - I can see traffic coming in for my IPs on interface "br0". I can also see traffic from my internal host using its IP on "eth0".

I'm trying to tell the router to simply relay all external traffic destined to one of my /29 (8 IPs) to my linux host, and return all internal traffic from any of my /29 sources of my 8 IPs to the internet.

Can anyone explain how to do this, or if it's the correct approach ?

I started with this, which fails with: iptables v1.4.21: Couldn't find target `NOTRACK':

 iptables -t raw -A PREROUTING -s 203.139.179.48/29 -j NOTRACK  

(and, for reference, the -t raw is empty as well)

I'm guessing I need to use the -t filter table instead, at the top (before NAT), somehow, although I'm not entirely sure.

Can anyone suggest rules to use? Should I be adding a "route" instead/as-well ? Do I need to spell out the interfaces to my modem, or should I give my linux box a LAN IP, and tell my modem to send all traffic to "that IP", but without actually mangling anything (e.g. leave the destination IP in the packet as 203.139.179.49 and just use the 192.168.1.x IP as some kind of means to understand which interface (eth0) it needs to go through ?)

Update: - I got one IP working with NAT, but I don't want to use NAT on my public IPs - I want direct for those. This is what got NAT going:

iptables -t nat -A DMZ_PREROUTING -d 203.139.179.49/32 -j DNAT --to-destination 192.168.1.250

(I set my linux box up on 192.168.1.250 - but as I said, I want to change that back to 203.139.179.49/29 (all 8 public IPs)). Here's how the tables looked before the above:

# Generated by iptables-save v1.4.21 on Thu Feb 25 21:25:24 2021


*raw
:PREROUTING ACCEPT [757713:146949682]
:OUTPUT ACCEPT [487359:155842609]
COMMIT
# Completed on Thu Feb 25 21:25:24 2021
# Generated by iptables-save v1.4.21 on Thu Feb 25 21:25:24 2021


*nat
:PREROUTING ACCEPT [3356:465245]
:INPUT ACCEPT [685:68545]
:OUTPUT ACCEPT [683:72201]
:POSTROUTING ACCEPT [861:82958]
:DMZ_POSTROUTING - [0:0]
:DMZ_PREROUTING - [0:0]
:MINIUPNPD - [0:0]
:POSTROUTING_MASQUERADE - [0:0]
:PRE_WAN_INFILTER - [0:0]
:REMOTEMANGE_PREROUTING - [0:0]
-A PREROUTING -j REMOTEMANGE_PREROUTING
-A PREROUTING -j DMZ_PREROUTING
-A PREROUTING -i eth0.1 -j MINIUPNPD
-A PREROUTING -i eth0.1 -j PRE_WAN_INFILTER
-A POSTROUTING -j DMZ_POSTROUTING
-A POSTROUTING -j POSTROUTING_MASQUERADE
-A DMZ_POSTROUTING -s 192.168.1.1/32 -d 192.168.1.250/32 -j ACCEPT
-A DMZ_POSTROUTING -s 192.168.1.0/24 -d 192.168.1.250/32 -j SNAT --to-source 110.243.62.22
-A DMZ_POSTROUTING -s 192.168.7.1/32 -d 192.168.1.250/32 -j ACCEPT
-A DMZ_POSTROUTING -s 192.168.7.0/24 -d 192.168.1.250/32 -j SNAT --to-source 110.243.62.22
-A DMZ_PREROUTING -i eth0.1 -p udp -m udp --sport 67:68 -j ACCEPT
-A DMZ_PREROUTING -i eth0.1 -p 47 -j ACCEPT
-A DMZ_PREROUTING -i eth0.1 -p udp -m udp --sport 1701 -j ACCEPT
-A DMZ_PREROUTING -i eth0.1 -p tcp -m tcp --sport 1723 -j ACCEPT
-A DMZ_PREROUTING -d 110.243.62.22/32 -j DNAT --to-destination 192.168.1.250
-A POSTROUTING_MASQUERADE -s 192.168.1.0/24 -o eth0.1 -j MASQUERADE
-A POSTROUTING_MASQUERADE -s 192.168.7.0/24 -o eth0.1 -j MASQUERADE
-A POSTROUTING_MASQUERADE -s 10.8.0.0/24 -o eth0.1 -j MASQUERADE
-A PRE_WAN_INFILTER -p tcp -m tcp --dport 8091 -j ACCEPT
-A PRE_WAN_INFILTER -p tcp -m tcp --dport 8090 -j ACCEPT
-A PRE_WAN_INFILTER -m state --state RELATED,ESTABLISHED -j ACCEPT
-A PRE_WAN_INFILTER -j DROP
COMMIT
# Completed on Thu Feb 25 21:25:24 2021
# Generated by iptables-save v1.4.21 on Thu Feb 25 21:25:24 2021


*mangle
:PREROUTING ACCEPT [42331:8881456]
:INPUT ACCEPT [29716:7485804]
:FORWARD ACCEPT [10415:1252489]
:OUTPUT ACCEPT [28687:7955617]
:POSTROUTING ACCEPT [39144:9224902]
COMMIT
# Completed on Thu Feb 25 21:25:24 2021
# Generated by iptables-save v1.4.21 on Thu Feb 25 21:25:24 2021


*filter
:INPUT ACCEPT [29588:7478145]
:FORWARD ACCEPT [10231:1241814]
:OUTPUT ACCEPT [28644:7927631]
:ALG_FORWARD - [0:0]
:DMZ_FORWARD - [0:0]
:GRC_INPUT - [0:0]
:MACFILTER_FORWARD - [0:0]
:MINIUPNPD - [0:0]
:REMOTEMANGE_INPUT - [0:0]
:WLAN_GUEST_LOGIN_INPUT - [0:0]
-A INPUT -j GRC_INPUT
-A INPUT -j REMOTEMANGE_INPUT
-A INPUT -j WLAN_GUEST_LOGIN_INPUT
-A FORWARD -p tcp -m tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
-A FORWARD -j MACFILTER_FORWARD
-A FORWARD -j DMZ_FORWARD
-A FORWARD -i eth0.1 ! -o eth0.1 -j MINIUPNPD
-A FORWARD -j ALG_FORWARD
-A DMZ_FORWARD -d 192.168.1.250/32 -i eth0.1 -j ACCEPT
-A GRC_INPUT -m state --state INVALID -j DROP
-A GRC_INPUT -p tcp -m tcp --dport 0 -j DROP
-A GRC_INPUT -p tcp -m tcp --dport 1 -j DROP
-A GRC_INPUT -p tcp -m tcp --dport 8081 -j DROP
-A REMOTEMANGE_INPUT -d 110.243.62.22/32 -p tcp -m tcp --dport 443 -j DROP
-A REMOTEMANGE_INPUT -d 110.243.62.22/32 -p tcp -m tcp --dport 80 -j DROP
-A REMOTEMANGE_INPUT -i br+ -p tcp -m tcp --dport 443 -j DROP
-A WLAN_GUEST_LOGIN_INPUT -d 192.168.1.1/32 -i br1 -p tcp -m tcp --dport 80 -j DROP
-A WLAN_GUEST_LOGIN_INPUT -d 192.168.1.1/32 -i br1 -p tcp -m tcp --dport 443 -j DROP
-A WLAN_GUEST_LOGIN_INPUT -d 192.168.7.1/32 -i br+ -p tcp -m tcp --dport 80 -j DROP
-A WLAN_GUEST_LOGIN_INPUT -d 192.168.7.1/32 -i br+ -p tcp -m tcp --dport 443 -j DROP
COMMIT
# Completed on Thu Feb 25 21:25:24 2021

What's the way to point traffic at an internal "public" IP? Is there a "-j NONAT" or similar trick that understands the "--to-destination" concept, without re-writing the IPs in the packet headers? (FYI - there's no other switches between my linux and the router).

Answer 1

Routing explanation

Your router has some WAN-facing IP, let's call it router_wan_ip. The IP on the "other side" of that link let's call isp_gw_ip.

If it's a PPP of any kind, chances are, your router gets its IP address router_wan_ip and remote IP address isp_gw_ip via IPCP protocol during session setup and default route is set by the pppd. If it's, say, Ethernet, often you'll get to enter your IP with subnet mask usually /30 (255.255.255.252) and set a default route by hand. Either way, your router has a default route via that isp_gw_ip.

You've got a block of 8 addresses, let's call it routed_subnet. It'll have a mask of /29 (255.255.255.248). Usually this means, an ISP router, which has address isp_gw_ip, installed a route like routed_subnet via router_wan_ip. So when someone in the Internet sends packet to any address inside routed_subnet, it reaches ISP router and eventually it routes that packet to your router.

How you use that block, is up to you.

Often you use it as an IP subnet, which means you sacrifice 2 addresses (all zeros and all ones). These couldn't be used. Then you choose any of remaining 6 addresses to be a LAN-facing address of your router. Often first available is used, it will have three last bits 001, but you are allowed to choose any for that, except 000 or 111 which are reserved by the protocol. You combine these bits with subnet address routed_subnet and get a complete router LAN address, let's call it router_lan_ip. Note the subnet mask will be /29.

Remaining 5 addresses of the subnet you assign to the computers in your network. If you chose 001 for router, these will be 010, 011, 100, 101 and 110. You combine them with routed_subnet and get complete addresses, with subnet mask again /29. Let's take one for the remaining discussion and call it computer_public_ip.

When you configure it on the computer, you also set a default gateway. Which one? Right, your router, router_lan_ip must be set as the gateway. Remember we considered a packet from the Internet to one of your IPs? Now computer, which was assigned that IP, has a route back to the Internet and can reply.

Packet forwarding on the router must be enabled, i.e. sysctl net.ipv4.ip_forward=1 must be run somehow. That's all configuration.

A router_wan_ip and isp_gw_ip are "link" addresses which don't appear anywhere in the normal internet traffic. They're not required to be public. Often they are, because error messages like ICMP dest unreach or similar are still use these addresses and so it's better they were public. But sometimes ISPs may choose to sacrifice that and don't waste additional precious public IP addresses.

The router_wan_ip and router_lan_ip may also be same address with different netmasks (one of them will be /29, other one /32). This is the way for ISP to have public IP there, but still not waste additional IP from public space. If that's the case, i.e. if ISP assignes you a link address which belongs to your subnet (e.g. via IPCP), better you use exactly that same address for the LAN side, or you'll use 2 of 6 available addresses on the router and have only 4 left for computers.

Some recap to this verbose and detailed explanation. All addresses here include their respective netmasks. Computer and router LAN addresses are taken from the address block which is assigned to you. It is not that exactly these commands get executed; ISP may use something other than Linux, for example, or pppd uses sligtly different. I only expressed everything in terms of Linux iproute2 commands for this section to look consistent.

On the router:

ip addr add router_lan_ip dev lan_iface
ip addr add router_wan_ip dev wan_iface
# ip route add isp_gw_ip dev wan_iface # if PPP
ip route add default via isp_gw_ip

ISP does for you on their equipment:

ip addr add isp_gw_ip dev facing_to_you_iface
# ip route add router_wan_ip dev facing_to_you_iface # if PPP
ip route add routed_subnet via router_wan_ip

A computer

ip addr add computer_public_ip dev iface
ip route add default via router_lan_ip

Firewall configuration

Notice, nothing I still told about iptables, because it's not a routing thing, but a packet filter/translator and it doesn't do anything with routing directly. By default, Netfilter just allows any traffic. Of course, it's still very useable to filter some traffic, the only difference for you now will be that you won't use NAT anymore, at least not for these 5 addresses with public IPs.

How to achieve this configuration in your router, I don't know. All professional routers require to enable NAT explicitely if it's needed; on the contrary, SOHO routers often assume you'll need it and it's enabled by default. In some SOHO routers you can still disable it if you want; however, I've seen boxes where NAT couldn't be disabled. If you see "NAT"or "masqurading" or "internet access sharing" options somewhere in the interface, that's probably it. For example, in OpenWRT firmware you may disable NAT by unchecking (or not checking) a "masquerade" checkbox on the WAN facing network in the general firewall settings.

You can also have some clients translated, and some (five addresses) not. For this, you need the following basic configuration:

iptables -t nat -A POSTROUTING -s routed_subnet -o wan_iface -j ACCEPT -m comment --comment "Packets from this subnet won't be NATed"
iptables -t nat -A POSTROUTING -o wan_iface -j SNAT --to-source router_lan_ip -m comment --comment "Other packets are source-NATed to the IP of the router itself"

The first rule simply catches packets from happy owners of public IP and ACCEPTs them early, don't letting them to reach second rule and get translated.

In cases when router has public router_wan_ip, second rule may use that address to SNAT to, either explicitely via -j SNAT --to-source router_wan_ip or implicitely via -j MASQUERADE. I used router_lan_ip because we know for sure it's public, because it was taken from public subnet routed to you. If router_wan_ip is private, probably you'll need to set up additional NAT rule like this for the router itself to have Internet access:

iptables -t nat -A OUTPUT -o wan_iface -j SNAT --to-source router_lan_ip -m comment --comment "Internetl access for the router itself"

Which addresses get other (NATed) machines in the network and where do they connect? It's up to you again. For example, simplest case is to have in the router a third IP interface for LAN with private addresses. Or your lan_iface can have two addresses (one public, other private) and both networks could share the same Ethernet segment.

All filtering (which packets are eglible to forwarding) must be done in the filter table, either INPUT and OUTPUT chains for packets to or from router itself, or FORWARD chain for the rest of the network; this includes packets between two LANs, even if they share same interface.

Again, I don't have an idea how to do this on your hardware. It's pretty easy to do on the Linux box; it's possible to do on OpenWRT, it can also be set up on any professional router.