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

Despite Masquerading Internal Addresses Appear On WAN-Interface

Xavier2
Hi,

my Astaro (9.106-17) is placed on it's WAN-Interface behind another router.
The Astaro is the only device behind the other router and there's just one link
between them.

On the Astaro for all internal networks masquerading is switch on by rules like
'Internal network XX' to WAN-Interface.

Everything worked unsuspicious and quite well until yesterday.

On the external router I switched on a feature called Backroute Verify on the interface to the Astaro.. This means that incoming data packets are only accepted over this interface if outgoing response packets are routed over the same interface.

The subnet between the external router and the Astaro is 10.15.95.0/24.
Astaro has 10.15.95.10. the other has 10.15.95.20
Therefore the external router drops all packets not coming from an address within that subnet. This should be no problem since masquerading is turned on.


The other router logs dropped packets. 
In the logs I can see a lot of of dropped packets from source addresses
behind the Astaro.

How can this happen with masquerading turned on?

It seems like the Astaro doesn' substitute the source address with it's own WAN address.

Surfing, Mailing everything seems to work from inside the Astaros's internal LANs.

But some TCP messages [RST or FIN,ACK odr RST,ACK] go trough. TCP Seq is always '1'.
Only these types of packets. No TCP payload packets and also no UDP.


I can see the with Wireshark too.

I've no clue.
What can I check?

Best regards
Xavier


-----------------------------

Sorry, by posting this messages there appear also some payload packets with internal addresses on the WAN Interface.


This thread was automatically locked due to age.
Parents Reply Children
  • 0 in reply to T-Roc_01
    Hi, I got a final answer from sophos.

    Here in German.

    Der Techniker hat dies zuammen mit einem Sophos Escalation-Engineer analysiert: Auch in Ihrem aktuellen dump sind Fin Ack’s sowie Reset-Pakete enthalten. Es sind definitiv Pakete, die unmaskiert ankommen, da in Ihrer Firewall die Connection-Tracking Tabelle eine beendigung der Kommunikation mitgeteilt bekommen hat, und somit diese Verbindung herausgelöscht wurde. Wenn nun ein weiteres Paket ankommt, wird es nicht mehr maskiert. Dies ist eine technische Gegebenheit, die auch mit anderen Firewalls auftritt, - hintergrund ist eine Firewall-Regel in der UTM, die any erlaubt. Ohne diese Regel werden „überschüssige“ Pakete nicht weitergesendet.

     
    Dies lässt sich mit dieser aktiven Firewall-Regel nicht vermieden, es ist kein Fehler in der UTM, und kann somit auch nicht beeinflusst werden. Der Techniker wird dieses Ticket somit abschließen.

    and in english

    The technician analysed this togehter with an sophos escalation egnineer:
    Even in your latest dumps there are fin, acks and reset packets. These are definitely packets that arrive unmasked, because the connection tracking table in your firewall has been notified about the end of the communication and hence deleted the connection from the table.
    If another packet from this communication arrives, after the connection got deleted from the table, it will not be masked.
    This is a technical condition which also arise with different firewalls, background to this is an any allow rule in the firewall. Without this rule, excess packets would not be transmitted.

    You cannot avoid this with this active firewall-rule, it is not a mistake of the UTM and can therefore not be influenced. The technician will close the ticket.
Cookie Information Banner