Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 7 replies
  • Subscribers 2 subscribers
  • Views 2240 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

More dumb port forwarding issues

Specific
So, it seems like problems with port forwarding are common, but I've read all the relevant threads and I'm not quite sure why this isn't working. OK, I am using ASL 4.000 currently, and I'm trying to forward port 80 (at the moment, more later) to my webserver, which lives on my intranet. I have only 2 NICs, eth0 which is my LAN connection, and eth1 which is my PPPoE connection. I already have NAT up and working perfectly. Here's some relevant info:

Services: (I added this)
http     tcp     s/port:80    d/port:80

Networks: (my webserver)
sonication    192.168.1.5   255.255.255.255

NAT/Masquerading:
Name: http
Rule Type: DNAT/SNAT
Source address: Any
Destination address: CenturyTel_PPPoE_Interface___
Service: http
Change source to: No change
Change destination to: sonication
Service destination: No change


Am I missing something important? Thanks for any help!

EDIT: Forgot to mention packet filter rules, which are currently set to All/All/All/Allow to keep that out of the way.


This thread was automatically locked due to age.
  • 0
    That should work, maybe the kernel is getting confused when trying to route the host specific "32bit"  255.255.255.255 mask. try adding a static route on your firewall to the web server via the intranet interface. assuming your internal interface is 192.168.1.1.... 

    add a static route

    192.168.1.5 via 192.168.1.1

    or try sliding back the mask on the ethernet address in you dnat rules. also i would run a sniffer on the internal network right after the intranet interface to see if indeed the packets are getting passed and perhaps your webserver is blocking them. one last thing, check to make sure your isp is not blocking inbound http. some isp's such as cable and dsl block inbound smtp, http, irc, ftp etc....  


    I would strongly suggest getting another interface and putting the webserver or any "Public" server in a DMZ if. running a public server on your intranet is just asking for trouble.
  • 0 in reply to EaSyToKeR
    Wow...I have no idea what you are talking about [:)]   
  • 0 in reply to Specific
    Your service definition is wrong.

    HTTP should be already defined in Astaro as a static defintion.

    Src Port = 1024-65535 Dst Port 80.

    Use that one.

    All's you need is a MASQ rule for the internal network to get out.
    Then add a SNAT/DNAT rule to forward traffic from the red interface to your webserver.
    (As you have done but your service definition is wrong).

    I tried this out on ASL this morning and it works fine.
    (I usually use public IP's for servers but tested to a private IP on my LAN).
     
  • 0 in reply to Simon Shaw
    Grr, I don't understand why this isn't working. Yeah, I'd origionally tried using the build-in definitions for HTTP, SSH, and POP3, but they didn't seem to work, which is why I added my own. I just went back and tried using them, after deleting my definitions, and it still doesn't work. (I have ssh access to the firewall disabled). Is there something else I can try, or a convenient display of all my parameters you'd like to see? 
  • 0 in reply to Specific
    You say your using OpenBSD? What version? Are you using the OpenBSD firewall ...ipfilter for versions 2.9 and below or pf for 3.0 and above? if your not using any firewall on the webserver then obvisouly this should not be a problem, however if you are check your pf.conf or ipfilter configs to make sure that you are indeed allowing packets inbound from the astaro intranet ip addy. 

    again if your internal ip on the astaro box is 192.168.1.1 your filters on the webserver should look like. 

    using for ex. dc0 as your interface on the webserver...you can find out exactly what yours is by typing

    #ifconfig –a | more

    pass in quick on dc0 proto tcp from 192.168.1.1/32  to (dc0) port 80 keep state.

    if you are using 3.0 or above pf  is smart enough to know that (dc0) is its interface and replaces (dc0) with the correct ip such as 192.168.1.5.

    you should also be able to specifiy www as the port instead of port 80. 



    pass in quick on dc0 proto tcp from 192.168.1.1/32  to (dc0) port www keep state. 


    a good rulset my be...

    scrub in all
    block in all

    pass in quick on dc0 proto tcp from 192.168.1.1/32  to (dc0) port www keep state. 

    The above would allow all packets with the ip headers set with the http service comming from 192.168.1.1 255.255.255.255 pass

    in order to access your webserver from an internal machine without proxing you will have to slide back the netmask.

    netmask is the 255.255.255.255, i think you said you were using a 24 bit mask internally which would be 255.255.255.0

    so…..

    in order to allow all web traffic comming from the 192.168.1.0/24 network a good rule would be....

    pass in quick on dc0 proto tcp from 192.168.1.1/24  to (dc0) port www keep state. 

    so now this expands to……

    scrub in all
    block in all 

    pass in quick on dc0 proto tcp from 192.168.1.1/24  to (dc0) port www keep state. 

    if you have ssh running on the webserver which is on by default in openbsd i would seriously consider restricting the access to only the internal machine you will ssh to the box from.

    using 192.168.1.3 as a internal machine....

    scrub in all
    block in all 

    pass in quick on dc0 proto tcp from 192.168.1.1/24  to (dc0) port www keep state. 

    pass in quick on dc0 proto tcp from 192.168.1.3/32 to (dc0) port 22 keep state.

    after you change ,modify, pf.conf you must reload the new rulset via.... # pfctl -f /etc/pf.conf   or reboot.


    if you choose not to run a fw at all on the webserver....

    type # pfctl -d 

    to keep the fw off after a reboot edit /etc/rc.conf with vi and set the value PF=yes to PF=no.

    You can take a quick look at the fw rules if you are indeed using the packet filter via...

    # cat /etc/pf.conf | more

    If your firewall is off as I showed how to do above and still not working then we will have to look into astaro future but check out the openbsd first to eliminate it as a guilty culprit.

    To see if packets are getting nated properly from astaro to that of your webserver…..

    On the openbsd box……

    # tcpdump –I dc0  replace dc0 with that of your interface.

    With tcpdump running get someone on the outside to try and access your box. If astaro is working you will see packets for port 80 from that of your astaro intranet int.

    note: you must create pf rules with a editor that uses unix format such as vi, or a good windows editor that free is http://www.notetab.com/  select the light version. if your using notetab make sure you set the options to save as "Unix"

    then you can push the new pf.conf to the openbsd box via ssh using another windows tool called winscp which is also free.














      
  • 0 in reply to EaSyToKeR
    Thank you very much for all of your help, this morning the old HDD that I was using for the firewall died, so I tried using IP-COP, and it is a better fit for my (low-scale) needs than ASL is [:)]n- 
  • 0 in reply to Specific
    I think you said the hd was an ibm correct? If the latter is correct let this be a future lesson on ibm hd's as they are truly a pice of ****. I had several fail before i wised up and switched to segate. Ipcop is a dam good fw, I have a box here in my home lab loaded with the current code testing it, hacking it etc... and reporting back to the dev team to help make it a better more feature rich product. You will see remarkable changes in the upcomming releases. The dmz "pin holing" and PAT " port address translation" or as cisco calles it NAT overload will probably suit all your needs. 


    Good luck.