Author Topic: [SOLVED] SNAT versus Port Forwading  (Read 17332 times)

christian

  • Guest
Re: SNAT versus Port Forwading
« Reply #30 on: July 04, 2013, 11:23:21 am »
Oops, sorry  :-[ so this means my English is definitely broken and too poor if you don't understand from the very beginning that I push you to:
- use reverse proxy for external connections
- configure DNS for internal connections.

I'll try to improve... but for the the time being, I don't know how I could be clearer  ???

Lonniebiz

  • Zen Samurai
  • ****
  • Posts: 320
  • Karma: +24/-2
    • View Profile
Re: SNAT versus Port Forwading
« Reply #31 on: July 04, 2013, 01:02:32 pm »
I resolved my issue with the source IP address being wrong on traffic from internet users to the windows web server by indicating a source IP range on the port-forwarders of the internal interface (eth1).

In order to do this, I had to create a networking object under the Networking > Objects menu that represented the entire range of IPs that any computer would ever be assigned on my LAN (192.168.0.1-254).

In summary, I've added 3 virtual interfaces to Zentyal's external interface, so that Zentyal can handle traffic for 3 additional public IP Addresses: 55.55.55.55, 55.55.55.56, 55.55.55.57.

I have a windows webserver inside the Zentyal network assigned these private IPs: 192.168.0.5, 192.168.0.6, and 192.168.0.7.

I essentially need the following mappings:

55.55.55.55:80 gets served by 192.168.0.5:80
55.55.55.56:80 gets served by 192.168.0.6:80
55.55.55.57:443 gets served by 192.168.0.7:443


This webserver serves over 40 websites. One website has a dedicated IP 55.55.55.55 (for SEO considerations) , and the other websites are mainly on 55.55.55.56, and the other IP is dedicated to a SSL website.

So that internet users can access the windows webserver via 55.55.55.55, I have this port-forwarder:

Code: [Select]
interface: eth0
Orginal Destination: 55.55.55.55/32
Protocol: 80
Source: Any
Destination IP: 192.168.0.5
Replace Source Address: No

So that internet users, will see 55.55.55.55 as the source address on replies by the windows webserver, I have this SNAT entry:

Code: [Select]
SNAT address: 55.55.55.55
Outgoing interface: eth0 eth0:object1, eth0:object2, etc
Source: 192.168.0.5
Destination: Any
Service: Any

So that LAN users may also access all websites served by 55.55.55.55, I added this port-forwarder to eth1 (not eth0). Also notice that I had to check the box for "Replace Source Address", which I didn't do this for my port-forwarders on eth0. Also notice that the source is a network object that represents the internal IP range, so that this rule is not applied to any internet sourced traffic:

Code: [Select]
interface: eth1
Orginal Destination: 55.55.55.55/32
Protocol: 80
Source: source object 192.168.0.1-254
Destination IP: 192.168.0.5
Replace Source Address: Yes


Here's the port-forwarder allowing internet users to access this same windows webserver via 55.55.55.56:

Code: [Select]
interface: eth0
Orginal Destination: 55.55.55.56/32
Protocol: 80
Source: Any
Destination IP: 192.168.0.6
Replace Source Address: No

So that those internet users will see 55.55.55.56 as the source address on all replies by the windows webserver I have this SNAT entry:

Code: [Select]
SNAT address: 55.55.55.56
Outgoing interface: eth0 eht0:object1, eht0:object2, etc
Source: 192.168.0.6
Destination: Any
Service: Any

So that LAN users may also access all websites served by 55.55.55.56, I added this port-forwarder to eth1 (not eth0). Also notice that I had to check the box for "Replace Source Address", which I didn't do this for my port-forwarders on eth0. Also notice that the source is a network object that represents the internal IP range, so that this rule is not applied to any internet sourced traffic:

Code: [Select]
interface: eth1
Orginal Destination: 55.55.55.56/32
Protocol: 80
Source: source object: 192.168.0.1-254
Destination IP: 192.168.0.6
Replace Source Address: Yes

Here's the port-forwarder allowing internet users to access this same windows webserver via 55.55.55.57:

Code: [Select]
interface: eth0
Orginal Destination: 55.55.55.57/32
Protocol: 443
Source: Any
Destination IP: 192.168.0.7
Replace Source Address: No

So that those internet users will see 55.55.55.57 as the source address on all replies by the windows webserver I have this SNAT entry:

Code: [Select]
SNAT address: 55.55.55.57
Outgoing interface: eth0 eht0:object1, eht0:object2, etc
Source: 192.168.0.7
Destination: Any
Service: Any

So that LAN users may also access all websites served by 55.55.55.57, I added this port-forwarder to eth1 (not eth0). Also notice that I had to check the box for "Replace Source Address", which I didn't do this for my port-forwarders on eth0. Also notice that the source is a network object that represents the internal IP range, so that this rule is not applied to any internet sourced traffic:

Code: [Select]
interface: eth1
Orginal Destination: 55.55.55.56/32
Protocol: 443
Source: source object 192.168.0.1-254
Destination IP: 192.168.0.6
Replace Source Address: Yes

Before, I was using "ANY" instead of the source object 192.168.0.1-254 for the source on the internal interface port-forwarders. This had the unforeseen ramification of also applying this rule for traffic coming in from the internet and it changed the source to 192.168.0.1 for internet sourced traffic . . .  making the windows web server think that all its traffic was coming from 192.168.0.1 (which isn't too helpful for web site traffic analytics). By narrowing the source scope from ANY to just the internal IP range, internet traffic was no longer affected by my internal interface port-forwarders.

I'd like to thank Christian, Half-Life, and jbahillo for teaching me the fundamentals that led to this solution.

 
« Last Edit: July 05, 2013, 01:36:25 am by Lonniebiz »

half_life

  • Bug Hunter
  • Zen Hero
  • *****
  • Posts: 867
  • Karma: +59/-0
    • View Profile
Re: [SOLVED] SNAT versus Port Forwading
« Reply #32 on: July 04, 2013, 07:39:32 pm »
Me earlier ---
Quote
Caution -- be careful not to include your Zentyal servers internal IP address in the snat -ed range.

I believe you just found the reason that I included that little tidbit.  You have it fixed now which is good.  I believe you can see how difficult this is going to be going forward if you expand further in terms of number of internal servers.  One more thing,  have you considered server outages and continuity in your design? 

All in all you have learned quite a bit about firewall rules with your approach and this is a good thing.  What you accomplished is very difficult and is to be commended.  Congratulations.

Lonniebiz

  • Zen Samurai
  • ****
  • Posts: 320
  • Karma: +24/-2
    • View Profile
Re: Continuity
« Reply #33 on: July 05, 2013, 02:23:14 am »
Yeah, I had to play with this myself a bit before I could truly understand what you had said. When I reread your replies later, my brain began to comprehend.

You asked if I had given any thought to continuity during server outages. Well, I know that any machine can break, and it is hard to cover every scenario without a large budget. However, here are my current thoughts.

If the Zentyal gateway were to break, my plan is to move some cat5 cables around. You see, the windows web server has 2 network cards. Initially, it was not behind Zentyal, and network-card-1 was assigned public IPs directly and was plugged directly into the ISP gateway.  When I added internal IPs to the windows webserver, I added them to Network Card 2. I then unplugged the cable from Network-Card-1 and plugged it into Network-Card-2 and the other side of that cable was moved to a switch behind Zentyal. So, if for some reason the Zentyal server breaks, I will simply plug the windows webserver into the ISP gateway directly again via network-card-1, and that network card is already set to serve the public IPs directly.

If the windows web server breaks, I'm going to have some more downtime, because I'd have to rebuild it from a backup. My plan it to get a better server, and convert that windows web server to a virtual machine and back up that virtual machine routinely. Virtual machines are nice, because if you have a backup of one, you can boot that back up from another physical machine if the primary machine fails.

So, at this point, my continuity plan is a be manual for this network.

I am administering another Zentyal network at a company, were I have a little more of a continuity plan. For example, there I have two Zentyal domain controller were one is replicating the other. DHCP issues IPs that include both DNS servers. I also have two dhcp servers on the same LAN with pools that do not overlap. I've tested the continuity at this company by shutting down the primary Zentyal server. After doing this, users were still able to login to their workstations just fine, and they also continued to get DHCP and DNS just fine. This continuity on this network is no so manual as the first.
« Last Edit: July 05, 2013, 02:27:28 am by Lonniebiz »