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

problem with packet filter rule and masquerading

eric_ang
Hi,

I noticed the following when using Astaro version 5.015

1) the logging option for the packet filtering rules will be reset whenever the "action" option is change for that specific rule. E.g Drop to allow

 2) when applying a new packet filtering rules, existing TCP session will not be affected. E.g drop all  ftp traffic, existing ftp session will still continue. Is there a way to reset the firewall state table?

3) When masquerading is applied for all internal network on the external interface..Eg PAT.  Why does host from the external network stiill able to initial/establish direct connection to the internal network  host? There is not SNAT/DNAT defined.

4) For SNAT/DNAT and masquerading rules, as there is no rules prority E,g numbers. Does Astaro firewall process the rules base on best match?

Sorry is there any thing/setting I miss out?

thxs
Eric


This thread was automatically locked due to age.
Parents
  • 0
    1) That's a known issue.

    2) I will test that an reply later. Does that happen only for FTP or also for normal traffic like SSH, HTTP, ... I am asking because FTP uses dynamic port allocation.

    3) Why should a masquerading rule drop packets? If you don't want packets to route through ASL, just disable the packetfilterrule that allows these kind of packets.

    4) As far as I know ASL processes the rules alphabetically.

    Xeno
  • 0 in reply to Xeno
    thxs,

    For point 3:
    Sorry what I mean is that normal firewall should prevent/deny connection generated from external host to the internal host under masquerading mode (Port address translation). However Astaro seem to perfrom PAT for going traffic (internal to external), but it still allow direct incoming traffic generated from external to internal?

    rgds
    eric
  • 0 in reply to eric_ang
    hi there, 

    if i understand you correctly, 
    you want to block traffic from the external network to the internal.

    Is there a specific reason why  the packetfilter is not enough?
    per default this should be blocked by the default policy DROP of the packetfitler.

    I know of configurations where you want excatly that configuration, 
    masquerade some packets out, but let other traffic still in.

    we see NAT not as a security mechanism.
    Use the packetfilter instead.

    regards
    Gert
Reply
  • 0 in reply to eric_ang
    hi there, 

    if i understand you correctly, 
    you want to block traffic from the external network to the internal.

    Is there a specific reason why  the packetfilter is not enough?
    per default this should be blocked by the default policy DROP of the packetfitler.

    I know of configurations where you want excatly that configuration, 
    masquerade some packets out, but let other traffic still in.

    we see NAT not as a security mechanism.
    Use the packetfilter instead.

    regards
    Gert
Children
  • 0 in reply to Gert Hansen
    thxs,

    Yes, I agree that PAT/NAT should not be used as security mechanism. However, if NAT/PAT is  perform first before firewall policies and masquerading is enabled on the external interface. Unsolicited traffic from the external network should be drop and not pass onto the firewall packetfilter, as there is no previous connection state in the firewall. Else why have separate masquerading and SNAT function? 

    Ref:
    http://linas.org/linux/load.html
    "Firewall Security through Masquerading"  section qoute:

    ' Masquerading allows insiders to get out, without allowing outsiders in. Masquerading re-writes the IP headers of internal packets going out, making it appear that they all came from the firewall. Reply packets coming back are translated back, and forwarded to the appropriate internal machine. Thus, inside machines are allowed to connect to the outside world. However, outside machines cannot: in fact, they cannot even *find* the internal machines, since they are aware of only *one* IP address, that of the firewall. Thus, they cannot attack the internal machines directly. '

    rgds,
    eric