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

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
  • Hi,

    I don't have 'connections', but I am probably one of the people they're referring to.

    What I have talked about in the past, is that hosting web servers (http/https) behind the firewall tends to create a lot of noise in the logs from 'expired' tcp connections, where the client or server tries to close the connection after it's already expired from the firewall's connection tracker, and then the firewall drops and logs the FIN/ACK and/or RST packets..

    Your problem may sound similar, but I don't think it's the same.

    AFAIK, in the webserver scenario, the firewall does not send out any packets.

    I'm confused though; SIP is UDP, so why are there FIN/ACKs at all?

    Barry
Reply
  • Hi,

    I don't have 'connections', but I am probably one of the people they're referring to.

    What I have talked about in the past, is that hosting web servers (http/https) behind the firewall tends to create a lot of noise in the logs from 'expired' tcp connections, where the client or server tries to close the connection after it's already expired from the firewall's connection tracker, and then the firewall drops and logs the FIN/ACK and/or RST packets..

    Your problem may sound similar, but I don't think it's the same.

    AFAIK, in the webserver scenario, the firewall does not send out any packets.

    I'm confused though; SIP is UDP, so why are there FIN/ACKs at all?

    Barry
Children
  • Hi Barry,

    the UTM leaks both.
    TCP datagramms, mostly FIN/ACKs and complete UDP datagramms.
    The first come from all kind of devices (Windows PCs, Linux servers, AppleTVs,...) the latter from the phones using UTM's VoIP gateway.

    As I first discovered this I filtered always for TCP connections that's why I didn't see the SIP UDPs.

    Xavier