Link to home
Create AccountLog in
Avatar of gopher_49
gopher_49

asked on

Windows 2008 with multiple IP's assigned to different source NATs

My firewall has two different subnets assigned to it's outside interface.  The first subnet has a series of NATs to the IP address 192.168.160.13.  I have a series of NATs on the other subnet to 192.168.160.41.  Both the .13 and .41 IP's are assigned to a single NIC.  The first series of NATs work just, however the second series does not.  The reason being is that they are replying on the wrong IP address on the outside interface.  My firewall has a source NAT rule that states all requests from 192.168.160.41 are you go out on the specified IP address.  This being in the second subnet, however, Windows is overriding this and sending it out on the first subnet.  I know my firewall rules work for I've used them on other hosts, however, those hosts didn't have multiple IP's on a single NIC.  Any ideas on how to make this work?
Avatar of Cliff Galiher
Cliff Galiher
Flag of United States of America image

Windows *can't* override your firewall NAT rules.   That just isn't how it works.

BUT.  Windows can send traffic out of the first IP address bound to a NIC. It is up to the application to specify which adapter(s) and which IP(s) to use. The application binds to these assets via Winsock. Many applications just grab *everything* and windows can't be psychic, so it has a simple logic. Highest bound IP wins unless the application specifies otherwise. So this is purely application-specific. You have to configure your application to send traffic out .41 or to reply on the same IP it received traffic on. And if the app doesn't support this...well....nothing you can do. You can even have this problem with multiple adapters if the application is not coded to bind only to specific adapters. Same simple logic. Highest bound IP on the highest bound adapter with the shortest routing metric (which, with two IP's on the same private subnet, means routing metrics don't apply unless you declare static routes.)
Avatar of gopher_49
gopher_49

ASKER

I'm using IIS..  So..  The NAT sends the traffic to 192.168.160.41, however, the reply is not coming from 192.168.160.41.  Due to this the source NAT on my firewall doesn't send the traffic out the correct IP.  I have this particular website bound to 192.168.160.41.. But.. It still doesn't reply back on 192.168.160.41
You can do this with IIS, but it isn't trivial, and certainly isn't default behavior. Keep in mind that IIS can act as a proxy and a reverse proxy, so it has a lot of sophistication under the hood. And it is used in so many different ways that assuming a "default" is never a good idea. Hence it falls back to Windows behavior unless you dig in and configure it.

Note that this is further complicated if you stuck with tradition and used 255.255.255.0 (/24) as the subnet mask for your two IPs. Then you have two addresses on the same subnet and that can definitely wonkify Windows.  If you can isolate those, you'll have better luck right out of the gate.
Can I assign a useable/public IP directly to a NIC and enable Windows firewall on that NIC?  I have a virtual NIC I can mount to it that is bound to my WAN network...  This will result in two different gateways,  however, they are different subnets.  If this won't work what exactly do I need to do?
That depends on your firewall. And having two gateways can also be a routing nightmare.  I don't have any good advice due to the complexity of the potential environment.
I thought by binding 192.168.160.41 to my website within IIS would result in the source IP being 192.168.160.41 which would honor my source NAT.  I wondering if introducing the remote access and routing service might work..  Maybe set a source NAT via it..
Won't matter. RRAS is still after IIS in the pipeline. You have to fix it in IIS.
ASKER CERTIFIED SOLUTION
Avatar of gopher_49
gopher_49

Link to home
membership
Create an account to see this answer
Signing up is free. No credit card required.
Create Account
Fixed it myself for all other options did not work.