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

the NAT looks fine! I think the Problem isn´t on the ASL, because if you didn´t made a rule like "Any    {http}  webserver   allow" and you don´t see anything in the Logfiles something is wrong. Your Packets do not arrive the extern Interface of your ASL.

For Test make a rule like "Any    http    webserver  Log drop". If you don´t see anything yet, look other things first...

I hope this helps

Sorry for my bad english

Basty  

Tried that rule (sounded like a good idea) but no dice.  "Any webserver any log drop" doesn't even drop my pings.

Now I hooked up my laptop to a switch on my WAN side and gave it another IP address in that public space(z.z.z.a).  Can't ping my z.z.z.z address, tho I can ping z.z.z.b which is the ASL's own WAN port.

So to summarize:

with a DNAT rule from z.z.z.z to y.y.y.y I can ping y.y.y.y from LAN x.x.x.x, but not from another WAN ip address.

I can also access ports 80 & 443 thru my web browser (Apache server) by hitting the y.y.y.y address from my LAN, but not from WAN.

No packets lost in packet log.  Whatever's happening, it's not being blocked by packet filtering.

And I know it's not my server (as opposed to firewall) that's causing the problem, because when I take the NIC off of the DMZ and plug it into a switch on the WAN and just let it be exposed to the world (well, with IPChains blocking all but 80 and 443)  [;)]t works flawlessly.

So upshot is, something's not working on the DNAT/SNAT or (what I think is more likely) there's a step I'm missing or getting wrong.  Therefore I request again:

  Will someone who has actually done it successfully, please post a step-by-step (assume the reader knows nothing) guide for enabling a server on the DMZ to be served by a public IP address of the WAN?  

Thanks

Dan  

Did You have put a packet filter rule
Any HTTP webserver allow
before any other drop rule?  

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.  

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  

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