NAT Latency?

Thank you for the response, though I believe the information you are asking for was contained in my original post...

We're running ASL v7.201 on ASG220 appliances with 512MB of RAM each.  The one with the added latency is only running firewall with NAT.  We don't use any of the spam/virus functions, or any other special options except the NAT FTP application helper.

With these being appliance units that we purchased from an Astaro reseller (ASG220) we do not know what CPU they have in there, but as mentioned it has 512MB of RAM.  Thanks again!

It could be the IPS that is adding the latency. You can tune it or turn it off and see if it makes a difference.
You are supposed to tune it by defining servers (http, db, smtp, ...) to protect.

Is 12MS really a big deal?

A faster CPU would make the IPS faster.

Barry

turn everything off except the nat and see what happens.  build in the right packet filter rules of course.

We have everything but NAT disabled already, unfortunately, and still seeing the "issue" as we perceive it.  The only rules in place on the filter are an allow all for outgoing traffic, and the automatic rules from the NAT routing setup.

So you have IM/P2P detection off also, right?

Have you checked the speed & duplex on all the network equipment, including the firewall?

ethtool eth0, ...

will show you that information on the Astaro console/shell.

Barry

the im/p2p detection is based on the ips so you ahve to go meticulously to fidn everything that could be on.  I would open up a ticket with your reseller on this aas well as something isn't right if everything is truly off.

So you have IM/P2P detection off also, right?

Correct.

Have you checked the speed & duplex on all the network equipment, including the firewall?

Yes, we have everything forced to 100/full.

i ahve seen forced settings cause issues between servers and switches leading to latency issues...put it on auto negotiate and see if that helps.

i ahve seen forced settings cause issues between servers and switches leading to latency issues...put it on auto negotiate and see if that helps.

That would go against any best practice document I've ever read, but I'll give it a try late one evening when I'm able to take the network down when it won't disrupt anyone.

I appreciate all of the suggestions.

I have personally seen, and fixed, about 10 times in my career, connectivity issues that boiled down to a switch port and client NIC not autonegotiating properly, or for some reason, not working together even when forced to certain speeds... most of the time it was a Cisco / 3COM thing, but also had an issue with certain 3COM NICs and 3COM switches.  Try forcing the speed to 100MB / half duplex on both ends.  Sounds dumb, I know... but a look at the switch or nic statistics should reveal the issue... look for a lot of CRC errors, etc...

it could be astaro and the particular mobo just don't get along..no two mobos even from the same maker with the same model are exactly the same due to the complexities of modern electronics.

I've had autoneg problems between Cisco switches and BroadCom NICs, esp. when a ethernet TAP was added.

William, he's running a 220, so it can't be a motherboard incompatibility.

Barry

oh yes it can...no two pieces of equipment are exactly the same.  I've had astaro balk at one sc440 only to work perfectly on another.  An incompatibility is most certainly in the cards..either that or he has a nic/cable/port issue.

oh yes it can...no two pieces of equipment are exactly the same.  I've had astaro balk at one sc440 only to work perfectly on another.  An incompatibility is most certainly in the cards..either that or he has a nic/cable/port issue.

oh yes it can...no two pieces of equipment are exactly the same.  I've had astaro balk at one sc440 only to work perfectly on another.

Dunno, that sounds like a bad piece of hardware, not an incompatibility.

Barry

I appreciate everyone's responses on this thread.  I still haven't been able to pin down the cause, though I suspect it's just the NAT engine being sluggish.  It could be a hardware issue but I'm not sure I want to try and convince support to loan me another unit for comparison right now.  The network is working, just not as fast as we'd like it to.  Thanks again!

FWIW, NAT isn't sluggish.

There may be another network problem which is being brought out by adding a device.
Try bridging the firewall and seeing if the latencies change.

Run 
ps aux|grep snort

and make sure that snort isn't still running (I had a problem in ASL long ago where it was still running even though IPS was "turned off").

Barry

Run
ifconfig
and look for any errors.
Everything except the RX/TX counters should be ZERO.

e.g.

eth0      Link encap:Ethernet  HWaddr 00:A0:C9:B8:8B:48  

          inet addr:1.2.3.4  Bcast:255.255.255.255  Mask:255.255.248.0

          UP BROADCAST NOTRAILERS RUNNING MULTICAST  MTU:1500  Metric:1

          RX packets:115248210 errors:0 dropped:0 overruns:0 frame:0

          TX packets:49389338 errors:0 dropped:0 overruns:0 carrier:0

          collisions:0 txqueuelen:1000 

          RX bytes:1277667633 (1218.4 Mb)  TX bytes:3387226476 (3230.3 Mb)



eth1      Link encap:Ethernet  HWaddr 00:90:27:2A:75[:D]5  

          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

          RX packets:46054475 errors:0 dropped:0 overruns:0 frame:0

          TX packets:47554998 errors:0 dropped:0 overruns:0 carrier:0

          collisions:0 txqueuelen:1000 

          RX bytes:2993638980 (2854.9 Mb)  TX bytes:2149527211 (2049.9 Mb)

Barry

Try bridging the firewall and seeing if the latencies change.

If I had enough external IP addresses to not need NAT I'd give it a shot.  Maybe over the weekend when nobody is here I'll do a backup and reconfigure it to see what happens and restore the current config when I'm done.  Couldn't hurt.

ps aux|grep snort

Took a peek and snort isn't showing up on the list.

Run ifconfig and look for any errors.

Looks good, here's the output...

fw1:/home/login # ifconfig

eth0      Link encap:Ethernet  HWaddr 00:10:F3:0E:5E:A9

          inet addr:192.168.1.1  Bcast:192.168.1.255  Mask:255.255.255.0

          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

          RX packets:8863122 errors:0 dropped:0 overruns:0 frame:0

          TX packets:10213530 errors:0 dropped:0 overruns:0 carrier:0

          collisions:0 txqueuelen:1000

          RX bytes:3927621303 (3745.6 Mb)  TX bytes:693476415 (661.3 Mb)



eth1      Link encap:Ethernet  HWaddr 00:10:F3:0E:5E:AB

          inet addr:75.145.194.1  Bcast:75.145.194.1  Mask:255.255.255.255

          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

          RX packets:10274188 errors:0 dropped:0 overruns:0 frame:0

          TX packets:8656286 errors:0 dropped:0 overruns:0 carrier:0

          collisions:0 txqueuelen:1000

          RX bytes:720766278 (687.3 Mb)  TX bytes:3895204293 (3714.7 Mb)

Well, the good news is that I decided to run some speed tests and traces this evening now that the office is cleared out, and the network looks like it should.  We're testing 17+ Mbps through our Astaro now.  Frankly, I don't know what changed from a few days ago, but it's dramatically faster now.  Perhaps one of the earlier changes took a while to kick in for some reason?

Thank you to everyone who made suggestions and offered assistance.

My guess is one or more of the following was the problem:

1. ISP slow
2. Something on your net consuming lots of traffic, or a misconfiguration allowing internet traffic.
Keep in mind that although Astaro is secure by default, it is possible to mis-configure it and allow outside traffic to use the proxies, etc.

Barry

1. ISP slow

I'm starting to think it may have been their gateway device.  I logged in to the web admin on the gateway and some of the options have changed since I was in there a couple of weeks ago.  They may have done a firmware update that corrected some unknown problem.  I'm also seeing that our traceroutes out to common destinations are showing fewer hops and lower values all around.  Here's to hoping it stays "fixed" for a while.

I was having the same issue. While I don't believe the issues were necessairly he same, I thought I would post my findings.
DSL modem in one office and ASG120 in the network rack. The two are separated by a 30 foot network cable.
 I have a 2m down and 512 up dsl modem but was only getting 400k down and 300k up. I put a layer three network switch at the DSL modem, between the ASG120 and modem. After a few minutes, the collisions began showing up. 
Moved the ASG120 from the rack to the cabinet where the modem is and problems went away. The 120 couldn't handle the connection over the 30 feet without complaining. The network switch didn't have an issue with it at all.
Replacing the network cable from the modem to the main switch and moving the asg120 back to the switch resolved the issues.
 I played with flow control and speed settings but nothing would resolve the collisions.
 To often, we assume since there is some communication, the cable between two devices should be fine. My issues were just another example of "Suspect EVERYTHING"!
 I only resolved my issue after applying the "divide and concur" approach.