Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 10 replies
  • Subscribers 2 subscribers
  • Views 4143 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

Yet another DNAT Query!

Pfrog
I am another convert having moved from Untangle and I have spent many hours reading numerous threads and the KB trying to solve a simple port forward problem.

I have a number of webcams on a single network which I access externally.  Each obviously has a different port allocated and I have, before Astaro, accessed the cams via the ext WAN IP  ***.XX.XX.X:80xx. 

I can still access all the cams internally.  I have the standard NAT Masquerade Rule for Int Network > External WAN in place.

I have set up a Service Definition:

WebCam 1
TCP
Dest Port: 80xx
Source: 1:65535

I have set up a DNAT Rule:

From: Any
Service Definition: As above
Going to: Ext Wan IP

Destination: IP of Webcam 192.168.1.xx
Service: Blank (I have tried service as above also).

Auto Firewall Rule activated.

The firewall live log shows packets being received to Port 80xx and not dropped (not red) but no access to webcam.  There is no other firewall in place,

I appreciate that I am doubtless missing something extremely simple http://www.astaro.org/images/smilies/frown.gif but any assistance greatly appreciated.


This thread was automatically locked due to age.
  • 0
    Hey Pfrog,

    What port are the webcams listening on internally?

    Most webcams with a builtin webserver are hard coded to use port 80 or 443. Easy way to check is to access the webcam's url in your browser. If you can access it via http://WebCamIP/ or https://WebCamIP/ it's running on a standard port so you'll have to add that to your DNAT rule

    From: ANY
    Going to: WAN
    Service: WebCAMPort (80xx)

    Destination: WebCamIP
    Dest Service: http(80) or https(443)

    See if that helps.
  • 0
    Two common new-to-ASG/UTM errors...

    Check to be sure that none of the Host/Network definitions you created is bound to a specific interface; all of your definitions should have 'Interface: >'.

    In DNATs, the 'Traffic destination' must be an "(Address)" object.  If you have a single WAN interface named "External," then you must use the "External (Address)" object created by WebAdmin when the External interface was defined.

    Cheers - Bob
  • 0 in reply to TheDrew
    Hi TheDrew and thanks for the response. 

    No, the cams are all Y-Cam and have configurable ports.  They are all in the 80xx range.  They are only reachable on the LAN with the port being appended to the local IP address.  What I am failing to understand is why I can see the packets in the Firewall log without being dropped / blocked, and yet no connection to the cam!

    Is there another Masquerade rule required.  My research shows not, but any thoughts gladly received.......
  • 0 in reply to BAlfson
    Two common new-to-ASG/UTM errors...

    Check to be sure that none of the Host/Network definitions you created is bound to a specific interface; all of your definitions should have 'Interface: >'.

    In DNATs, the 'Traffic destination' must be an "(Address)" object.  If you have a single WAN interface named "External," then you must use the "External (Address)" object created by WebAdmin when the External interface was defined.

    Cheers - Bob


    Hi Bob...

    In the Network Definition for the Cam I have the "Any" option, and I am using the Ext Wan Ext Address object in the rule itself.  

    Thanks  Pfrog
  • 0 in reply to Pfrog
    Just noticed in the Kernel Message log that every time I try to access the cam via the Ext IP:80xx, I have the following entry:

    2012:09:25-15:14:49 Sophos_UTM kernel: [72955.300537] host 192.168.1.75/if3 ignores redirects for 192.168.1.190 to 192.168.1.190. 

    .75 is my local PC, and .190 is the cam.

    Does this give any clue to the problem please??
  • 0
    Ahhh - maybe this is what you need: Accessing Internal or DMZ Webserver from Internal Network

    Did that work for you?

    Cheers - Bob
  • 0 in reply to BAlfson
    Ahhh - maybe this is what you need: Accessing Internal or DMZ Webserver from Internal Network

    Did that work for you?

    Cheers - Bob


    Hi

    Thanks but no!  I do have the proxy enabled and tried it to no avail, but I don't think it is applicable as I can access all the network PCs, webcams etc internally on the local PC.

    What I cannot do, despite the DNAT rule described in my first post, is to access the webcams using the external WAN IP with the relevant cam port appended :80xx.  What I would describe as a simple Port Forward exercise and something I have managed on numerous occasions in the past on many different pieces of kit /other UTMs.  This is not to criticize Astaro as it is a great UTM but clearly needs time to learn to drive it.

    The KB you have referred to seems to be the opposite problem - unable to access internal webserver from PCs located within the network, but works OK from external locations.

    Thanks  Pfrog
  • 0 in reply to Pfrog
    Just noticed in the Kernel Message log that every time I try to access the cam via the Ext IP:80xx, I have the following entry:

    2012:09:25-15:14:49 Sophos_UTM kernel: [72955.300537] host 192.168.1.75/if3 ignores redirects for 192.168.1.190 to 192.168.1.190. 

    .75 is my local PC, and .190 is the cam.

    Does this give any clue to the problem please??


    This sounds like what Bob described later on in the thread. Are you doing your testing from an IP address outside the internal network, or just from inside and trying to access the external IP?

    The thread Bob referenced also applies anytime you are trying to access an external IP from inside the firewall. So if from your local PC you are typing http://MyExternalIP:80xx/ you're running up against this.

    What happens with a DNAT is the firewall translates the destination IP & port but keeps the source IP intact. The firewall also does a sanity check and if it sees an internal IP as the source IP for the DNAT, it chokes because it sees that as invalid, hence your error message.
  • 0
    Yes - it does work and much relief!  Thanks all for the help as I was indeed trying to access the ext WAN IP from within the network - something that I have been able to achieve on other kit but evidently not possible on the more tightly controlled Astaro.

    Thanks again!
  • 0 in reply to Pfrog
    Glad we could help.[:)]

    One thing you'll find as you delve deeper into Astaro is that a lot of things work on the principle of "what isn't explicitly allowed, is denied" or "default deny." It does make for more work setting things up but it also results in a more secure system overall.