Basic DNAT/SNAT question

Hi,
---to use your webserver from your LAN with x.x.x.x you dont use the ASL box.
---to use your webserver from your LAN with y.y.y.y you have to make a packetfilter-rule for it in your ASL box.
---to use your webserver from the web with y.y.y.y you have to make a packetfilter-rule/NAT-rule for incomming, and a NAT-rule for the outgoing packets from your webserver for it in your ASL box.

firebear   

Is it possible that I need a packetfilter rule when my packetfilter logs show no dropped packets?  Doesn't make sense. . .  

I have tried one, it doesn't make any difference.  Nor would I expect it to, as there are no packets showing dropped in the packet filter log.  

HELLO ASTARO????

Some documentation from the authorities would be awfully nice here. . .the manual has nothing useful!  

Hi Dan, got your private message.  Hell you know about as much as me on this [:)]

To get servers working from outside normally I just create a packet rule to allow the traffic and a SNAT/DNAT rule to forward to the internal network.

Have you created a masq rule for the DMZ ?  That would probably help.

Your initial NAT rule looks good.
Any port 80 traffic to external IP, forward to web server inside. Dont change source address. Dont change service, just change destination.

Unfortunately for you I have a whole Class C public address for my DMZ so don't need to mess with SNAT/DNAT.
 

Dan,
I just tested to my internal LAN with IIS 5.0

Created a packet filter to allow port 80 traffic from Red to InternalIP
Created a SNAT/DNAT rule to forward port 80 traffic to Red to the internal web server IP.

And it works.

(Try Any Any Any Allow for testing).

Maybe your install is corrupted ?  I've had weird stuff happen once before, packet filters and some definitions were not working as expected.  Backed up config and reinstalled ASL and restored config fixed it.

 

Simon,

Will you try another experiment for me?  'Cause I tried what you said, and it works for me too, but it's not (quite) what I wanted to do. . . [:(]

Being the nervous little dog that I am,  , I really don't want to have my firewall's Red port accept   ANY  traffic from the outside world. . .that is, for a webserver I want the IP to be one of the other ones I legally own in my public space, but to simply tell ASL that it should never, under any circumstances, accept any traffic originating from the outside world and intended for its own IP address.

Therefore, what I wanted to do, was to create a DNAT rule that translated that other public IP address into my webserver's address (and put it on the DMZ eventually, not the LAN).  Problem is, though the incoming traffic works just fine, the webserver's responses are then slammed by ASL as IP-spoofed packets and never get out the door.  And that seems to be something over which I have no control.

So how can one use ASL to route multiple legitimate public IP addresses (in the same subnet)?  Do I change my DMZ's IP space to be the rest of my /27?  I thought (and am now configured this way) that the DMZ should be another private IP space and only use DNAT/SNAT to provide the public IPs as necessary. . .but obviously this isn't working. . . [:S]

Thanks for answering; for some odd reason ASL personnel seem unwilling to join this discussion. 

Dan  

I think I understand what you are saying.

Your "normal" fw red interface is say 1.2.3.4
You want to add a public IP to the interface ?
so Red = 1.2.3.4 AND 5.6.7.8 ?

Then use 5.6.7.8 for web server ?

This should work...

I have private LAN address 192.168.X.X
I have a Class C block I use for DMZ (203.11.69.X)

I have also put some of those Class C addresses on my Red interface for remote access to machines on my LAN so I can use terminal services to do remote admin.  These use DNAT rules to forward to my private IP's and seems to work fine.

Normally though, web servers/mail servers etc etc use public IP's in my DMZ so there is no requirement to have people accessing my firewalls red interface.

Only time traffic gets to red interface specifically is when I am using terminal services and I have these packet filtered so I can only do remote access from certain IP's.

ASL Staff are slow to respond sometimes.  Not sure if this is because they are busy, the questions are from people who haven't paid for a license or whatever....
Sure is frustrating sometimes though when your stuck and you're sure that 20 seconds of attention from an ASL staff member would probably solve something you've been driven crazy over for 24 hours or longer....

I'm still trying to get MSN working through firewall but I doubt it will ever happen till SIP/uPnP comes in, (And I think ASL stated they will never support uPnP) [:(]

If you are a paid up license holder, try emailing support direct ?  Shame those responses/questions don't get posted here or to a knowledge base...

A decent searchable knowledge base would be excellant.
 

Simon,

If I correctly understand what you're saying, then your DMZ itself has nothing between it and the outside world?  I thought the traffic to DMZ passed thru Red interface but was routed to DMZ instead of LAN (which is how I tried, unsuccessfully, to set up mine), the idea being that the DMZ still had controlled access, but was something that the world could see *some* of without exposing your LAN.

Here's my setup with more specifics:

My public IP space is a /27:  209.233.x.x.  That gives me 15 IP addresses to use--one of them is the Red address on ASL; the other 14 are not in use at all.  I have set up a DMZ 10.3.x.x, and a LAN 192.168.x.x.

What I thought I would do for my webserver was to set it up on the DMZ, give it one of those 10.3.x.x addresses, and then set up a DNAT rule taking one of my WAN /27 addresses and pointing it to that DMZ webserver address.  When I did that,  I was able to ping the 209.233.x.x address of my webserver from within my own LAN (that is, ASL was doing some routing), but not from a true outside box.

When I tried to access that IP from an outside box, my packet filter log showed that ASL stopped the return packets (from my webserver to the external computer) because those packets were going thru Red and being spoofed as the other public IP address.  This is what appears to be stopping the whole process, and this is what I can't seem to get around.

Just to make sure that was the only problem, I changed my DNAT rule to take port 443 traffic from my Red IP address (instead of the other 209 address) and send it to my webserver.  Because packets returned that way are being MASQed as Red again, they went thru happy as a clam.

What am I missing here???

BTW, I'm a paid licensee (three different installations), but I feel that their support subscription prices are prohibitively high so I'm not subscribed to that.  Unfortunately, that seems to result in about the same level of support as any free-download user, at least where some (though not all) ASL staff are concerned.  It appears the only thing you really get with a paid license is that warm feeling from having legal software. . . . . .which said warm feeling and $0.50 will just about buy you a donut!

D  

Yes, nothing between my DMZ and the outside world *except* tight packet filters.  ie, only allow web traffic to web servers, only mail traffic to mail servers etc...

So yes, my DMZ is not NAT'ed or MASQ'ed at all.
This seems secure as long as you keep a good eye on your packet filters.  (The way you are doing it appears to my untrained eye just as secure).

To do what you are doing you need to allow access to the IP from external.

IE:
From Service To Allow
Any  Whatever PublicIP Allow
Then you need a rule:
Any Whatever PrivateIP Allow

That should get your SNAT/DNAT rule working ?

 

Dan,

get the support tools from 
http://docs.astaro.org/older_versions/ASL-V3.2/docs_v3/hacking/
follow the instructions on how to copy and decompress it.

This package includes tcdump a very helpful packet sniffer.
Code:

---

 
PATH/tcpdump -i eth(outside) host_ip and port 443

---

where host_ip is the IP address of the device the request will come from
Tcdump should show the incoming HTTPS requests

If you perform the same for the dmz interface
Code:

---

 
PATH/tcpdump -i eth(dmz) host_ip and port 443

---

and you see leaving packets towards your server your problem isn't on ASL and
you'd have to go on  investigating on your server.

read you
o|iver



        

Oliver,

Thanks for the reply.  I'll try it, but maybe I asked the question wrong.  I *know* packets are leaving the ASL box and going to the server; without it the server wouldn't be trying to reply.  The issue is that the server's reply packets are being stopped by ASL because they are spoofed as the assigned IP address but trying to travel through Red.  The sniffing you suggest isn't going to help track that down, is it?

If it'd help I can email you a copy of a packet filter log that shows you the errors I mean. . .

Dan  

Oliver,

Thanks for the reply.  I'll try it, but maybe I asked the question wrong.  I *know* packets are leaving the ASL box and going to the server; without it the server wouldn't be trying to reply.  The issue is that the server's reply packets are being stopped by ASL because they are spoofed as the assigned IP address but trying to travel through Red.  The sniffing you suggest isn't going to help track that down, is it?

If it'd help I can email you a copy of a packet filter log that shows you the errors I mean. . .

Dan  

If SPOOF_DROP appears there is something wrong with you network setup at all!
Please make sure that your server doesn't have an address which belongs to another
network attached to a different network interface.

If you have double checked and you are sure that there is nothing wrong wizh your
IP settings please send login data to support@astaro.com - to lead 
this thread to an end [;)]

read you
o|iver  

With my great thanks to Oliver Desch from Astaro, who logged into my system to see what was wrong, I was setting the whole thing up incorrectly.  Here are the correct steps:

1)  Under Network/Interfaces, define the public IP address of your server as an additional interface on the hardware that corresponds to your RED eth. interface.  This means that there will be two (or more) legitimate IP addresses on your RED card, but don't worry, this does work.

2)  Create a DNAT/SNAT rule translating the destination of packets intended for that public IP address to whatever private or DMZ address you intend to use, along with whatever protocols you intend to use (in my case that's HTTPS)

3)  Create and enable a packet filter rule allowing the appropriate traffic (in my case HTTPS) to hit the internal, private IP address that is the target for the server.

With these three elements, the server works fine.

Again my thanks to Oliver  for sorting this out. . .the missing element for me was the missing alias for the public IP address on Red.

Cheers,

Dan  

What do you mean by RED card?? Is that the one connected to the internet? 

What if you do have a dynamic public address?  

By RED I'm merely referring to the WAN, or unprotected public side of the firewall.  The RED interface is the one that receives incoming traffic from the outside world, and has a public IP address.  

  Poster: uzweifel
Subject: Re: Basic DNAT/SNAT question--SOLVED!  

What if you do have a dynamic public address?  
  

I don't think DNAT/SNAT would work if  you have a dynamic IP address, but I also don't think it matters.  The purpose for DNAT/SNAT is to provide masking of a specific outside IP address to an internal one, and that outside IP address can only be hit by the public if it's a static address.  In other words, you can't host a web page on a dynamic IP address for the simple reason that there's no consistent place for the users out on the "net" to request web information.

Masquerading, on the other hand, is very useful with a dynamic IP.  This is what allows your multiple computers on your (internal) LAN to share the dynamic internet connection that is your dialup, cable, or DSL connection.  But again, it's not going to help for people trying to access content that you are hosting, because there's no single place (that is, static IP) they can go to seek it.

Hope this makes sense; feel free to post a further question if you need to.

Dan  

Am i wrong now or what's about DNS? DNS (AFAIK) would resolve this problem.  

DNS can only refer a user to an IP if the DNS has an entry to do so, and if that DNS itself is fixed (has a fixed IP).  AFAIK, there is no DNS provided by an ISP that will give an up-to-the-minute answer to the question "what dynamic IP address has Joe Blow been assigned this time?".  And you can't run your own DNS to answer this question unless you have a static IP address for that DNS. . .and even then, with a dynamic IP it couldn't get the correct info populated to the other DNSs of the net in anything like a timely manner.

Besides, a dynamic IP is assigned when you make a request to connect. . .by definition that means you're not always truly connected to the network (this is how PPPOE works).  Therefore, if I wanted to access your server and you didn't happen to be online at the moment, I'd be SOL regardless of whether the DNS could give me an address or not.

So no, I don't think DNS will help you on this front.  Bottom line, if you want to host content, you need a static IP.   

The answer for Dynamic DNS is (for example) www.dyndns.org
This Service will provide you a dns entry with a dynamic ip address. I am doing this at home quite successful. With this configuration i'm running Apache (and other Services like Mercury-Mailserver and War-FTP) on my 'kitchen server'.

I'm connected with ADSL to the internet and i think this is handled by PPPoE. But my Provider is not cutting the line, so i'm 'permanently' connected.

so back to my question: how can i use a HTTP-Server with ASL and dynamic IP?   

Well, I apologize for my ignorance that such a thing was possible.  That said, as I look at the DNAT/SNAT settings, it looks to me like they'll accept any named network or network range you've set up in your definitions.  So for example, if you define an IP range as whatever the range of addresses from which your dynamic IP can be assigned, and give it a name (say, RedIP), you should then be able to use that range as the destination for a DNAT/SNAT rule.

But that's all theory, since I don't have a dynamic set-up with which to experiment.  Try it and let us know what happens!

Cheers,  Dan