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

Problems with Masquerading in 4.017

Hi all,

i'm running in some problems with masquerading on ASL  4.017, working on 2 DELL1650 with HA option.
Since installing 4.017 (sorry, additional note on astaro board came too late) masquerading is failing sometimes.

I have bound one public ip address (A) with masquerading on the internet port for all outgoing traffic.
INTERNET Private_Network_192.168.0.0 -> All / All   MASQ__INTERNET   None
adress (A) is bound to interface INTERNET

Additional i use a different second public ip address (B) bound with NAT for outgoing mail server traffic out of DMZ2.
SNAT_DMZ2_MAIL01_SMTP    DMZ2_iHOST_MAIL01 -> All / SMTP   address(B)   None

An other server in DMZ1 is doing automatic update with FTP to special servers around the internet. Address (A) is assigned to this server because of masquerading.

All was working fine here. After installing 4.017 i have noticed that sometimes the outgoing traffic from DMZ1 is using address (B) instead of address (A). This is dramatic because some special servers does check our ip address for granting access. This behaviour may occur between 2 outgoing FTP sessions within 1 minute!

Any hints or ideas? Any help is appreciated!

cu Stefan  


This thread was automatically locked due to age.
Parents
  • status,

    make sure that your additional interfaces  have a 32 bit mask and no default gateway is assigned.

    read you
    o|iver

      
  • Many thanks for your support!

    @bagira:
    There are no additional informations for this problem to see in kernel log.  :-(

    @oliver.desch:
    That could be the good hint!  :-)
    All additional interfaces were supplied with a 29 bit mask and had the same default gateway as standard interface.
    Have been changed now - I'm full of expectation now...  :-)

    cu Stefan
      
Reply
  • Many thanks for your support!

    @bagira:
    There are no additional informations for this problem to see in kernel log.  :-(

    @oliver.desch:
    That could be the good hint!  :-)
    All additional interfaces were supplied with a 29 bit mask and had the same default gateway as standard interface.
    Have been changed now - I'm full of expectation now...  :-)

    cu Stefan
      
Children