# Static IP Server setup with a router?

## eccerr0r

Well, curious of peoples opinions and experience:

Currently I own a small subnet of public IPV4 addresses.  This way I can set up a server that's fully exposed to the network, and its IP address matches the outward facing IP address.  For my workstations and client machines that don't need an outward facing IP address I run NAT through a pfSense firewall to one of my other IPV4 addresses.

However this comes crashing down as I am forced to make a decision whether to change to a different ISP.  The problem is that this ISP I can only have one outward facing IP address.  So my server would be forced to do NAT.

While I can manually maintain an iptables script, or perhaps some other solution, this seems like asking for trouble when trying to setup a whole set of NAT mappings and bandwidth QoS settings.  It would be nice is if I could still have some sort of router/firewall that could juggle mappings, but it'd have to take up the sole IPV4 address that I'd be allocated, which may be a problem.

But I hear of "Transparent Routing"...what is it? What I don't quite understand is the concept of "transparent routing" -- is it possible to set up a router at my public IP address, and my server also have the same IP address (for things like keeping its certificates linked up properly to its reverse DNS, etc.)?  Sort of confused how it would be possible for a router to have an IP address and forward packets to a machine with the same IP address.

Does this make sense?  Does something like this actually work, and do people do this kind of stuff frequently?  What bothers me is that this kind of setup there's no guarantee a specific port would be available and if a mapping needs to be done, it would need something done in the router where it would be automatic if I just used the iptables script.

----------

## Tom_

Using NAT for incoming traffic is quite common, especially in corporate environments. Most of the time, public facing servers don't have a public ip address : you don't want to have a server directly accessible from the Internet. You want your servers to be in dmz (with a private ip address - https://tools.ietf.org/html/rfc1918), behind a firewall : the outside firewall is responsible for NATing incoming traffic to internal servers in a dmz. 

Your pfsense firewall is perfect for that! 

Ssl certificates are associated to FQDN (or wildcard dns records) but not to ip addresses. 

If your FQDN is www.mysite.com, then your certificate should be valid for www.mysite.com, whatever ip address associated to it is.. From the internet, www.mysite.com points to your public ip address (1.2.3.4). In your DMZ, this website is hosted on a server (80/443) having a private ip address : 192.168.0.2. Your firewall will "forward" incoming traffic on 1.2.3.4:80/443 to 192.168.0.2:80/443. It's fully transparent for the users. 

On your internal network, www.mysite.com could even resolve to 192.168.0.2.

----------

## Hu

I concur with Tom_.

To respond a bit further to a question from the original post: you generally won't assign the public IP to both the router and the internal server.  However, you could configure the router to forward all incoming unsolicited traffic to a specific internal address.  This is the DMZ that Tom_ mentioned, and would allow the internal server to act almost exactly like it actually had the public IP address.  Some routers are sufficiently configurable that you can define specific rules that override the DMZ default.  For example, you could have:

1.2.3.4: router / public IP

192.168.0.2: HTTPS server

192.168.0.3: SMTP server

192.168.0.4: ssh server

192.168.0.5-8: network-using clients that should never receive unsolicited inbound traffic

192.168.0.9: DMZ

With the right rules on the router, unsolicited traffic on port 443 will go to .2, smtp traffic to .3, port 22 to .4, and all others to .9.  I keep mentioning unsolicited for a reason.  Your router would NAT all traffic from all internal systems, so (subject to any filtering policy you chose to use), they would all have full outbound connectivity.

As Tom_ says, maintaining proper CNs on your certificates is entirely separate from this concern.  You can get the desired results with both your old and new topologies.

As for specific ports: the only time you need a specific port is on the public IP managed by the router, and you would use explicit rules as described above to pick which internal server gets traffic for an incoming request.  For outbound traffic, the router will just assign an ephemeral port, which may or may not be the same number as the port the internal client sees itself as using.  The router will remember that assignment and automatically remap responses to the correct internal client.  This way, all your clients can believe they bound :12345 on their respective internal IP addresses, they can all connect to the same external IP 7.8.9.10:443, and everything works.  The only quirk is that the server running on 7.8.9.10 won't see all the connections as coming from :12345, and may not see any of them as having that port, depending on what the router decided to do.  Very few protocols will care about this quirk, and those that do are generally condemned by anybody who works with NAT because they complicate usage of NAT and rarely have a good reason to cause those complications.

Theoretically, you can get into trouble with NAT due to port exhaustion, but in my opinion, any network with enough systems in operation to seriously risk that would (1) need a full time professional IT staff (probably more than one person) for other reasons, and (2) probably have access to additional public IPs and more complex systems, which would mitigate the situation.  Based on what OP wrote, I don't think the network in question is big enough to generate enough load to worry about this problem.

----------

## eccerr0r

So, if you set your internal server for 192.168.0.3, should you reverse DNS (on your local DNS server) of 192.168.0.3 (say SMTP server) -> your public facing FQDN in case some server software wants to look up its own IP address to record a response?  I surely cannot reverse DNS 192.168.0.3 to localmailserver.local - I've been bitten by this before hence the concern.

And then same with 192.168.0.2 (say webserver) or other machines/servers - have them also reverse to the public FQDN just in case they reverse their locally assigned IP address and report that to clients?

Then you'd have reverse dns for a whole bunch of local machines to the same address... that seems like a recipe for disaster too when you have other machines trying to monitor those machines and reverse dns is useless (have to log.  Granted there seems to be specific servers specifically SMTP that are quite sensitive to what your reverse DNS looks like.  How should these be handled?

Let's also ignore "unsolicited" traffic for now or assume I want to actually receive them with a large capacity machine for forensics and/or analysis.

----------

## Hu

I would consider it a bad behavior if a server looked up its own name and then forwarded that to a client.  The client should already know the name, or should do the reverse lookup itself if it needs the name.  Thus, I would not bother with reverse-mapping any of the internal IPs to a public name.

My point about unsolicited traffic is that if you receive a packet you aren't expecting, the router needs to know where to send it.  Otherwise, it is dropped and the client times out.

----------

## eccerr0r

While for HTTP it would send the target FQDN which makes things nice and simple as the server could just spit that back, but for SMTP, the internal IP address would be necessarily recorded in the hop log and it would reverse lookup the local IP name.  I'd imagine this name would be sent out which could be confusing, at least it was causing me grief when I was working with it before.  The direct public IP address, things just work ... perfectly.

I might have to do some experiments while I still have the subnet.  It's unfortunate I have to trade the block of routable static IPs down to just one to get a monthly rate discount and possibly two orders of magnitude improved bandwidth...

----------

## Hu

I seem to recall seeing private range addresses in mail received over the Internet, and sometimes private-looking names for them.  As far as I know, this is not a problem since the headers are not inspected in detail by machines because their content is not sufficiently constrained to make such inspection viable.  So many senders already do things badly that enforcing good behavior is impractical.

----------

## eccerr0r

Oh... NOW I remember exactly what the issue was.  I was having a huge time getting SMTP working because remote servers were insisting I run identd on my host so that it knew the source machine had root access to send the mail.  Now there are proxying identd servers out there provided I'm actually running a regular Linux install on that host - which means I can't depend on a canned firmware router.

Now I don't know if most SMTP relays stop requiring identd, but it had been a requirement in the past.  So I'd lose identd support if I depended on NAT?

On another note, most IRC still requires identd, or at least I think they still do.  If I truly had two unique users of the same IRC server, both would identd differently on a directly connected computer.  Through NAT, this breaks, so have IRC servers stopped requiring identd and people doing ~*@identdless.host channel banning not to mention the irc server itself checking for identd?

I've always hated running servers, especially ssh servers behind NAT because most NAT boxes tend to start dropping mappings when a connection sits idle.  On a direct connect host, one knows when the port stops listening.  A NAT box doesn't have that luxury... wonder how much RAM is needed to keep up with *all* connects in case they were all legitimate and not drop them due to timeout unless it really gets a FIN packet, and not worry too much about SYN attacks...

----------

## Hu

You could NAT the identd port to a Linux system where either a traditional or proxying identd was available.  This would not require more complexity of the router than you are already requiring for NATing the other connections.

I cannot comment on whether it is common practice for IRC to require identd.  I thought that had died off years ago because it was too unreliable.  Among other things, Windows did not enforce the restriction that low ports were reserved for privileged listeners, so Windows users routinely ran bogus identd-compatible listeners that would say whatever the to-be-identified client wanted.  This made querying a peer's identd pointless even when it worked; widespread use of firewalls further impaired use of identd.

For some protocols, such as ssh, you can configure the client or server to generate TCP keep-alive packets.  This is often a good idea anyway, as you do want to drop a connection where the other end has died.  Without a keep-alive, the connection can linger indefinitely until some other event forces a transmission.

----------

## eccerr0r

No, you cannot simply forward identd to another machine.  The NAT router that has the public address is the only machine that has all the information necessary to fully retrieve data to resolve identd requests.

I actually wrote a script to automate resolving identd requests using a forwarded machine long ago.  I had to probe the router in an ugly hack to figure out true identd results.  It was especially ugly because the router was slow, buggy, and did not like being probed, and crashed frequently.  This is an unacceptable solution at least due to the speed and bugs.

----------

## Hu

Forwarding the identd request to an internal machine is easy.  Accurately resolving all the requests may not be, but identd data has been so unreliable for so long that I wouldn't concern myself with anything more than returning a well-formed response.  Returning accurate data doesn't seem useful to me, since it is so rare for the peer to make good use of it.

----------

## Tom_

I've never heard of identd   :Surprised:  I don't really see why it would still be a requirement for a SMTP server in 2020.

Stateful firewalls usual drop idle connections whether these connections are NATed or not. It's a good thing to configure keep alive when possible.

----------

## eccerr0r

Hopefully someone who has actually implemented a full SMTP server over NAT would chime in...

All I can say at this point is that I've tried doing this in the past and was not completely successful.  Several, but not all remote servers would drop mail because of the NAT setup.

Note that keepalive also depends on the remote host and no remote hosts will tailor to your own esoteric requirements.  Ideally all "default" routing would be passive and not require state maintenance.

Getting more and more discouraged at a separate NAT server - still seems like I have to make the server also do NAT as well as regular services.  *sigh*

----------

## pietinger

 *eccerr0r wrote:*   

> No, you cannot simply forward identd to another machine.  The NAT router that has the public address is the only machine that has all the information necessary to fully retrieve data to resolve identd requests.

 

???

eccerr0r,

do you need identd for your smtp-server, for irc, or both ?

If you need identd only for one host, you should not have any problems with DNATting port 113. If you really have problems use oidentd instead ( https://en.wikipedia.org/wiki/Oidentd ).

If both, then I must tell you this will not work with only one (global) IP-address. Regardless which router or host does masquerading and DNAT, you must always configure a "port forwarding" to the target station.

e.g. for smtp (with identd) you must configure:

Any traffic reaching your router (or host doing NAT) on port 25 must be send to host 10.1.1.1:25; and any traffic reaching your router on port 113 must go also to 10.1.1.1:113

If you use IRC on another station (also in combination with identd) you will have no chance to "split" incoming traffic for port 113 to 10.1.1.1 and 10.1.1.2

----------

## eccerr0r

Ideally for any case in general if possible, so yes, both or any number of hosts.

Well, as hinted earlier, I was able to sort of do it to deal with any number of hosts even with an unfriendly router.  The router would plain DNAT to my main server and my main server would go back and grab data from the router.  Then it would go and hunt at the real machine that initiated the port and grab data, and then finally send the data back.  Problem is that three hosts were involved and it was SLOW.  I don't want to do this again as the script was custom for my router that I had back then (*#@&$#ing cisco riddled with bugs), this was unpleasant to do along with slow, was hoping the requester wouldn't timeout for the proper response.

For a direct connect host it's much easier, I can just run IRC on that host as well as smtpd.  Then if I'm feeling really bored, make the script forward requests if it finds the port is actually a NAT connection...

So is there not any documentation (semi) transparent routing, is this even possible?  I'm thinking this should save me a lot of hassle, else I would have to go bridging and do away with pfSense completely and reinvent pfSense functionality on my server in Linux...  Unfortunately as I think more and more about it, this too is sort of problematic if another NAT host uses a port that the transparently routed host uses, there's no way for the transparently routed host would know ahead of time it was in use, and we're dead in the water again - cannot do this solution.  ugh.

----------

## pietinger

 *eccerr0r wrote:*   

> Currently I own a small subnet of public IPV4 addresses. [...]

 

As far as I understand, your ISP gives you a "little bit of nothing" to get your IPv4-addresses ?!

I never would give up these addresses ... But maybe  ... if I get something for it, for example ... a new range of IPv6-addresses ... for my existing servers ...

I dont know your situation in USA, but is there no other ISP ?

----------

## eccerr0r

I get crap bandwidth plus the public ipv4s for more money than another isp that gives two orders of magnitude more bandwidth with only one public IPv4 with no option of getting 2 or more IPV4s...

Oh I have IPv6s with the IPV4s.  Several /56's actually IIRC.  I think with the other ISPs I'll get only one /64 but that's hardly a shortage even if it's a lot less...

I think my ISP has been slowly increasing the rental price to make me pain for keeping the static public IPV4's... it kind of hurts right now due to the bandwidth so it's a conundrum.

Yes you heard that right, TWO orders of magnitude.  Think about an average ISP speed nowadays and take off two orders of magnitude.  Then you'll see how slow my ISP is, and all my static public IPV4s are bottlenecked into them...

Right now my wire options are....

- extremely high monthly price, get multiple static ipv4s and zillions of ipv6, and bandwidth of crap

- moderately high price, get 1 static IPV4 and a less than zillions of ipv6, and nice bandwidth

- moderate price, NO static IPV4s, ??? Ipv6, and average bandwidth.

None of the wireless options have static IP so I rule them out.

Make your choice....

BTW I wish I could sublet these IPV4 addresses so I can get some ROI from them, but with the bandwidth so low, nobody would want them...

----------

