7.20 - Forced to reload the entire box..

essh good to know, i am gonna update my three boxes tomorrow.  i have static gateway routes set though, not static interface routes.

I updated my boxes this morning and only had one small issue, for some reason the box altered one of my packet rules after updating.  It was an easy fix but still curious.

tiredofnick: what exactly has been changed or what was not working after applying the Up2Date?

well it had turned a rule "off" but the green light said it was "on."  The rule definetly had been on and working correctly right before i updated.  to fix it, i just turned the rule off and on again and it started working fine. :shrug:

that particular box has always been a little funny.  i recently purchased an update to my support license, when i applied the new license to that box it "forgot" a bunch of its routes (static and gateway) and i had to rebuild the route table to get it working correctly.  I even tried rolling back to a backup config and it didn't work!

but like i said, all is well now.

Hi Marcel.

I'm sending you today's MDW log.
About the other suggestion - right now I can't stop my system, so i have to restart mdw fast as possible in order to keep my system running.

I'll try tomorrow morning.

Thanks…
[:)]

tiredofnick: do you use any kind of DNS definitions in your rules or routes which might not be updated/resolved and therefor not set?

Goldy: thanks for the log, can you please upload /tmp/mdwdebug.log from that box after this problem has occured but _before_ you reboot the box? Do you use QoS?

marcel:  nope, nothing like that.  and now that the day has progressed and people are at my sites i found an interesting problem, maybe you can advise a better stratagey? 

here is some background, I have three sites, which are all interconnected by a private WAN (PWAN).  2 of those sites have servers in a dmz.

And here is what happened.  Something changed in the order in which packets are processed (or something...).  Before we routed on just the PWAN address, since everything that is in the DMZ gets NAT'ed to its pwan address this worked fine.  Now NAT-ing happens before routing.

this is what was happening:
packet comes in bound for the pwan address 192.168.100.30 -> NAT translates the address to the DMZ address of 192.168.10.30 -> routes take over, but no route is explicitly set for 10.30 only for 100.30 , packet drops.

Obviously to fix it I just added in the apporpriate routes for all the DMZ ip addresses instead of the PWAN addresses, so i guess i had it setup incorrectly all along.  but its funny that it worked for so long and then died with this update.

make sense?

Hi Marcel

right now it's happening more often (I think there is more load on the Astaro).

Yes I'm using QOS.
Concerning QOS - I have noticed there is no way to config the priority of the new Traffic Selectors (DSCP).

Unfortunately, I can't leave my 500 users in this situation, So I guess tomorrow I'm going back to 7.104...

Now I'm loosing connection every 30 minuets.
It's also almost impossible to work with the WebAdmin.
[:(]

Goldy,

please upload /tmp/mdwdebug.log from that box _after_ the problem happened and _before_ a reboot has been issued - otherwise I can't help you.

thanks,
~marcel

Goldy,

please upload /tmp/mdwdebug.log from that box _after_ the problem happened and _before_ a reboot has been issued - otherwise I can't help you.

thanks,
~marcel

tiredofnick,

DNAT always came before routing - this did not change in 7.200. Maybe it was related to another change. Having a route for the DMZ network is best way to go.

best
~marcel

tiredofnick,

after checking all the changes I must revise my last posting - there has been a change regarding policy routes which have been checked before DNAT on 7.1xx and moved after DNAT in 7.200.

maybe this answers your questions [:)]

~marcel

Hi Marcel

I couldn't download the log because it was locked.

I have worked with Nils from Astaro today, and i think they have found the reason.

If you know something please let us know.