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. . .  

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  

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  

  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