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

Generic proxy works but DNAT doesnt

support@computer-ss.com
I have two wans, and am using policy routing so that the DMZ goes out the second one.  I want to forward incoming wan2 3389 traffic to a host on the dmz.  When I try the generic proxy it works fine, the host answers 3389 from clients on the net.

I then tried to setup a dnat rule to do the same, forward 3389 to that same host on the DMZ.  It doesn't work......... My packet analyzer on the desired host doesn't show any packets are coming in.

The reason I want to use DNAT is that I have multiple aliases on WAN2.

Any input would be appreciated.


This thread was automatically locked due to age.
Parents Reply Children
  • 0 in reply to BAlfson
    If I check the "automatic packet filter rule box", isn't that taken care of?
  • 0 in reply to support@computer-ss.com
    I don't know.  The 'automatic packet filter rule' is new in V7.  I prefer explicit packet filter rules so I can see in one place what's allowed where.  So, yeah, that's a habit and not a conscious decision based on familiarity with the new possibility.

    Does anyone here have experience with automatic packet filter rules?  Are they simply creating from the DNAT information a rule 'Source -> [Translated] Service -> [Translated] Destination : Allow'?  Is that a rule added at the bottom or the top of the packet filter rule list inside the Astaro?  Or does the Astaro just assume that the packet should be delivered and deliver it?  I assume the OP's approach obviates my concern, so...

    Check the differences between 'Generic Proxy' and DNAT rules.  I would check to see if you have a policy route that makes things work with the proxy but not the DNAT.

    Cheers - Bob
  • 0 in reply to BAlfson
    Bob... I have played around with the automatic packet filter rule checkbox... and it does appear to work. However, we don't deploy any systems using this feature, just my stubborness I guess.  I like having the rules separate, where I can view them, and enable logging etc. at my discretion.  I would recommend the OP try configuring a rule manually and enable logging to see what's happening.
  • 0 in reply to BrucekConvergent
    I'll see what the logs have to say.  I'll report back with my findings.

    Thanks!
  • 0 in reply to support@computer-ss.com
    14:01:15  Packetfilter rule #1  TCP 
    69.181.243.202  :  3440
    → 
    20.184.118.93  :  3389


    Thats what Astaro shows when I try to connect from an outside computer.

    Why does my source say 3440? Shouldn't they both be 3389?
  • 0 in reply to support@computer-ss.com
    Source can be any port above 1024 normally.
  • 0 in reply to Simon Shaw
    Source ports are randomly chosen by most TCP/IP programs from the range starting at 1024 and ending at 32768.
  • 0 in reply to BrucekConvergent
    Oh, and since it's RDP that you're having the issue with... check your IM/P2P blocking logs (if you have that enabled) and check your IPS logs... several rules in each can / will cause issues with RDP connections.  Specifically, I've had a lot of problems with the IM/P2P module blocking valid RDP connections, it detects them as "Winny" connection attempts.  I've had to disable that rule.