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

Trying to get traffic through Astaro 220

crburchett
I am trying to allow traffic to pass through port 5100 to an internal IP address.  I have created a packet filter rule as follows:  External >> Service (port 5100) >> Device.

Internal traffic passes over the port without issue.  However, external traffic can't get through.  I have placed the rule at the top of the list in an effort to bypass all others, but it still won't work.

Any insight would be greatly appreciated.


This thread was automatically locked due to age.
Parents
  • 0
    Is the internal IP in a private range? If yes, you must already have Masquerading activated. To directly pass specific external traffic to an internal host, you must create a DNAT rule.
  • 0 in reply to trollvottel
    You should search for this information here and on the Astaro KnowledgeBase.

    I would eliminate the PF rule and create a DNAT rule:

    Traffic Source: Any 
    Traffic Service: [Port 5100 service]
    Traffic Destination: External (Address)

    NAT mode: DNAT (Destination)

    Destination: [Host definition Device]
    Destination Service: [leave blank]

    Automatic packet filter rule: checked


    Cheers - Bob
  • 0 in reply to BAlfson
    Automatic packet filter rule: checked


    I've had some discussions about this. Big advantage is that you don't have to create separate packet filters, and you define everything for this particular port in one place. Disadvantage is that you cannot log taffic, and you will always have to look in two separate places to see what ports are enabled for the outside world.

    Given the latter two reasons, we don't check this in DNAT, but create a separate rule. What's the general opinion here?
  • 0 in reply to khardeveld
    khardeveld, I agree to some extent.  I just this year began using the auto rules.  Now I prefer them, but will uncheck one and replace it with a rule at the top of the packet filter rules when I need to debug.  I keep an inactive rule there all the time so the rule numbers don't change, and Rule #1 in the PF log is always my debugging rule.

    Version 7.5, now in beta, allows you to log auto rules.

    I like using auto rules now because it cuts down on the clutter in the explicit PF rule list.

    Cheers - Bob
Reply
  • 0 in reply to khardeveld
    khardeveld, I agree to some extent.  I just this year began using the auto rules.  Now I prefer them, but will uncheck one and replace it with a rule at the top of the packet filter rules when I need to debug.  I keep an inactive rule there all the time so the rule numbers don't change, and Rule #1 in the PF log is always my debugging rule.

    Version 7.5, now in beta, allows you to log auto rules.

    I like using auto rules now because it cuts down on the clutter in the explicit PF rule list.

    Cheers - Bob
Children
No Data