SRX

We are implementing our first production SRX240, and discovered that the MSRPC and DNS ALGs have already given us problems with a local domain controller (unable to dynamically register an A record, and unable to effeictively communicate back to the core domain controllers using MSRPC.  After disabling these two ALGs everything started working as expected.

The security policy between the two zones in question is permit any/any.

I'm curious as to what ALGs people have disabled by default due to expeirencing problems when their enabled.

We usually disable "sccp" and "sip", as they tend to "break" realtime voice/video streams from time to time. 

I would disable them all, and only enable individual ALGs if needed. To many intermittent problems otherwise.

I start by dissabling them all and then enabling the ones I know work and need.

I disable all that are not used on those segments.

Rather than disabling an important common ALG (Which I consider DNS to be) I would see what I could do to troubleshoot it - did you try different message size limits (the DNS ALG applies to TCP aswell as UDP and if you aren't using AD integrated between your DCs they will use larger TCP packets as part of the zone transfers)? Or do a selective bypass with a new UDP/TCP//53 matching app set to ignore ALG as the application in an early policy matching just those servers.

SIP and H.323 always seem to get broken by ALG.

Ya, it seems the ALGs are always at fault for first time deploys as they really screw up basic stuff in there default state..

IE SIP and H323 randomly fail or you get strange DNS issues that scew up other things.

They are very useful but I think having them ALL OFF and then enabling them one by one is a far safer during a deploy.

So what about FTP ALG? Isn't it needed to make FTP work over NAT?

We once had some major issues with an ALG (unfortunately I can't remember which one it was) and Juniper told us not to disable it because it would break things. Instead, they recommended to upgrade Junos to a fixed version.

In another deployment (very new) we see DNS problems and I am wondering whether to turn off the DNS ALG or not.

Just curious. 

True some of the ALGs are needed for NAT etc, however these are still things you should review during deploy.

For example if you don't review the release notes for the FTP ALG you may miss the fact that it has an extra paremeter that needs to be enabled if you also want to support FTPS traffic.

The ALGs are kind of strange if you ask me since they do very different things, some block / protect, some proxy, some do port triggering, some manipulate data, etc.

This means with them all turned on you have some that are blocking and some that are allowing by default... You turn them all off and you have the same thing, some things are blocked but some things work.

The difference is that with them all turned off it is EASY based on what is not working to figure out which ones to turn on.

On the other hand a combination of the DNS, SIP, RTSP ALG could cause DNS lookups to fail and block SOME SIP traffic... Since it isn't all or nothing you could spend a lot of time chasing ghosts...

Ok, here is an example:

Running Junos 10.4R6.5 on SRX650. People complain that connecting to SSH servers takes 20 seconds or more. Turns out those SSH servers have DNS reverse lookups turned on for each client connection and it seems to fail. We haven't found out why yet. Since this only popped up after replacing a Cisco PIX with this SRX, the culprit is clearly on that box.

You guys think disabling the DNS ALG might help here?

cryptochrome,

I would try disabling the DNS ALG if you don't need it for something else (DNS Doctoring comes to mind). One other thing you could try is to set the maximum message length for the alg:

set security alg dns maximum-message-length 8192

I think a key point that has been made already is you need to understand what the ALGs are actually doing per-protocol/application before playing with them. For example why would DNS inspection prevent a reverse-lookup? It shouldn't at all since essentially it's there for message-length checking/enforcement, DNS doctoring and only allowing the first DNS reply through. A reverse lookup is just a normal DNS request to the FW so check the basics, are the packets allowed by policy? What do the logs tell you on the DNS server (are the requests even getting there)? Is there something different about how the OS on the SSH servers creates the DNS requests (size etc.)? Once you're 100% sure it's not something simpler then try the message size adjustments already suggested, but again before completely disabling a core ALG like this I would create a custom application set to ignore ALG and permit it for select problemetic connections. That way you don't potentially break anything else while you test.

---

@Ahriakin wrote:

I think a key point that has been made already is you need to understand what the ALGs are actually doing per-protocol/application before playing with them. For example why would DNS inspection prevent a reverse-lookup? It shouldn't at all since essentially it's there for message-length checking/enforcement, DNS doctoring and only allowing the first DNS reply through. A reverse lookup is just a normal DNS request to the FW so check the basics, are the packets allowed by policy? What do the logs tell you on the DNS server (are the requests even getting there)? Is there something different about how the OS on the SSH servers creates the DNS requests (size etc.)? Once you're 100% sure it's not something simpler then try the message size adjustments already suggested, but again before completely disabling a core ALG like this I would create a custom application set to ignore ALG and permit it for select problemetic connections. That way you don't potentially break anything else while you test.

---

See, that's the thing. Of course we already checked all the basics like logs, tcpdump and what not, but we could not find anything.

The SSH servers are setup very strange. They are Unix, and the people who set them up did not create a /etc/hosts file. The applications on the server constantly try to figure out their own hostname, so instead of having it resolved locally, they pump those requests out the net. And they are millions. No kidding. So the SRX gets bombarded with all these DNS requests. While it doesn't seem to care at all (does not seem to have any impact on the machine's performance at all) we see those strange effects.

One could argue: Get your servers straight. And we tried. But they are the customer, they don't want to change the server, and they think that since we deployed a new firewall, it must be our problem.

Anyways. I will try with the max message lenght setting (thanks) and if that doesn't help, I'll try to completely disable it.

One more question: If and when the ALG does something (like only letting the first DNS reply pass through) - will we see anything about it in the logs? What should I look for?

Again thanks, and sorry for kind of hijacking the thread.

In my example, there was nothing in the logs indicating that the ALG was actually denying/dropping traffic, it just broke silently.  Is there a specific message type I should be looking for?  Where do logs go from ALGs that are dropping traffic to aid in troubleshooting?

---

@ecables wrote:

In my example, there was nothing in the logs indicating that the ALG was actually denying/dropping traffic, it just broke silently.  Is there a specific message type I should be looking for?  Where do logs go from ALGs that are dropping traffic to aid in troubleshooting?

---

Each ALG has trace options you can enable to view logs for them which are not on by default (again this is why each one should be tested and enabled one by one)... However if I recall correctly you should still see some basic indication that the sessions are being dropped in the main log, however you will need to have the ALG trace enabled to see the why.

I've seen evidence of DNS ALG causing memory leaks (and thus "weirdness" - technical term) pre 10.4r4. It's been fine from 10.4r6 on as far as I could tell in my own deployments.

I disabled the MGCP ALG as we got hit buy one of the bugs which caused the cluster to crash and core dump....  Fixed int 10.4r6 i beleive.

Is there a complete list of AGLs? Which ones do you disable?