Routing LAN back from WAN

M

morpheusrising

I'm having an issue routing on a specific client site.

Our configuration consists of a 3xT1 data line backed into a FreeBSD 5.5p10 system (I know, we're upgrading it over the Christmas break this year) that provides IPFW2 and NATD services to manage routing WAN IPs to LAN IPs on our various subnets.

We host several web systems on these subnets and our normal policy is to modify external DNS and internal DNS separately so that everything is optimized. For example, we would set store.mycompany.com on the external DNS to point to the WAN IP and set store.mycompany.com on the internal DNS to point to the LAN IP.

This method has served us well for years and allow us to roll with a lot of changes very rapidly.

However, we now are working on a project that requires us to do things a bit differently. We need our internal systems to be able to go to np.mycompany.com and utilize only the WAN address for the resolution.

When we do this, we get timeouts from our internal systems. Basically, the web browser just sits and spins forever.

My traceroute and ping work just fine, but the that's it.

In addition, if I configure a local system to utilize a dedicated WAN address and plug it directly into the external router of the 3xT1 interface, I get success.

So, my conclusion is that I have something missing in my routing that is preventing this from working when behind the firewall. I guess it could also be a firewall entry, but I've testing doing an allow all and still get the same results.

I just have the feeling that I'm missing out on something very simple and that soon I will be hanging my head low to my own ignorance.

Thanks in advance for any thoughts anyone might have.
 
Are you using port forwarding to access the websites from the WAN side?

If so you're probably running into this same issue: Thread 25321
 
SirDice said:
Are you using port forwarding to access the websites from the WAN side?

If so you're probably running into this same issue: Thread 25321
Click to expand...

I'm not forwarding specific ports, I'm doing it with redirect_address in NAT.

Of course, that's really just like forwarding all ports, so perhaps I'm falling into the same restrictions, even though the requested IP is not the same as the requesters IP (we have a large IP bank). I know that forwarding back on the same IP for separate port selection is goofy, but I would have thought that we had circumvented those issues by using different source and destination IP addresses and ignoring ports altogether.

Additional thoughts? or, should we chalk this up to the hazards of building in a DMZ?
 
How many interfaces on the firewall? Are the clients and the servers on the same private subnet? Or do you have a DMZ setup, where the servers are on a separate subnet from the clients?
 
morpheusrising said:
I'm not forwarding specific ports, I'm doing it with redirect_address in NAT.

Of course, that's really just like forwarding all ports, so perhaps I'm falling into the same restrictions, even though the requested IP is not the same as the requesters IP (we have a large IP bank).
Click to expand...
One port or all of them doesn't matter. It's the same issue.

I know that forwarding back on the same IP for separate port selection is goofy, but I would have thought that we had circumvented those issues by using different source and destination IP addresses and ignoring ports altogether.
Click to expand...
Different problem. You can't "bounce" off the same interface as the packets came in.
 
phoenix said:
How many interfaces on the firewall? Are the clients and the servers on the same private subnet? Or do you have a DMZ setup, where the servers are on a separate subnet from the clients?
Click to expand...

We run several subnets. In this case, the servers are located on a separate subnet from the servers. They are also on separate physical interfaces, backbones, etc.
 
Okay, if you have multiple interfaces on the firewall, and the traffic is going across multiple interfaces, then you can configure "double-NAT". This allows you to use public IPs everywhere and systems on each subnet never see the private IPs. (It took me 10 years of using IPFW to figure this one out.)

The following variables are used to show how the rules are organised:
$srv_pub = the public IP of the server
$srv_prv = the private IP of the server

$client_pub = the NAT IP for the client subnet
$client_prv = the private IP subnet for the clients

$srv_int = the network interface in the firewall connected to the server network
$client_int = the network interface in the firewall connected to the client network
$pub_int = the network interface in the firewall connected to the public Internet

Code: 
# Configure the general natd process for the LAN
/sbin/natd -port $port1 -same_ports -use_sockets -alias_address $client_pub

# Configure the natd process for the server
/sbin/natd -port $port2 -same_ports -use_sockets -alias_address $srv_pub -redirect_address $srv_pub $srv_prv

# NAT the traffic coming from the client LAN to the server
ipfw add divert $port2 ip from $client_prv to $srv_pub in recv $client_int
ipfw add allow         ip from $client_prv to $srv_prv in recv $client_int

# NAT the traffic going to server from the client LAN
ipfw add divert $port1 ip from $client_prv to $srv_prv out xmit $srv_int
ipfw add allow         ip from $client_pub to $srv_prv out xmit $srv_int

# NAT the return traffic, coming from server to the client LAN
ipfw add divert $port1 ip from $srv_prv to $client_pub in recv $srv_int
ipfw add allow         ip from $srv_prv to $client_prv in recv $srv_int

# NAT the return traffic, going to the client LAN from the server
ipfw add divert $port2 ip from $srv_prv to $client_prv out xmit $client_int
ipfw add allow         ip from $srv_pub to $client_prv out xmit $client_int

The general flow of the rules above is (src --> dest)
client private IP --> server public IP
client private IP --> server private IP (after first NAT)
<firewall makes routing decision>
client public IP --> server private IP (after second NAT)

Return traffic:
server private IP --> client public IP
server private IP --> client private IP (after first NAT)
<firewall makes routing decision>
server public IP --> client private IP (after second NAT)
 
I think this might be on the right track. I plan to do some testing this weekend during my client's downtime.

The question I have is that we're using several subnets and interfaces, here's the breakdown:

1. Firewall Public Interface (supporting 10 ip addresses, 1 main and 9 nat)
2. Client subnet A
3. Client subnet B
4. Client subnet C
5. Client DMZ subnet

So, does this mean that I need to do the operation you have listed for every combination of Public IP vs. Client Subnets? By my calculations that would be 27 operations.

Does that sound right?

Thanks in advance.
 
You must log in or register to reply here.
Back
Top