05-21-2010 12:10 PM
"Only problem with this release so far has been the DNS alg, which has been blocking DNS replys with CNAME pointing to the base domain address (IE www.asp.net CNAME asp.net, etc.) so I disabled the DNS alg."
I think we give you a nerd-knob in 10.1R2 to tweak the default DNS response packet size.
10.1R2 release notes includes the following:
DNS doctoring support—This feature is supported on all SRX Series and J Series devices.
Domain Name System (DNS) ALG functionality has been extended to support static NAT. You should configure static NAT for the DNS server first. Then if the DNS ALG is enabled, public-to-private and private-to-public static address translation can occur for A-records in DNS replies.
The DNS ALG also now includes a maximum-message-length command option with a value range of 512 to 8192 bytes and a default value of 512 bytes. The DNS ALG will now drop traffic if the DNS message length exceeds the configured maximum, if the domain name is more than 255 bytes, or if the label length is more than 63 bytes. The ALG will also decompress domain name compression pointers and retrieve their related full domain names, and check for the existence of compression pointer loops and drop the traffic if one exists.
Note that the DNS ALG can translate the first 32 A-records in a single DNS reply. A-records after the first 32 will not be handled. Also note that the DNS ALG supports only IPv4 addresses and does not support VPN tunnels.
05-24-2010 09:01 PM
As a followup to my previous post, our SRX 240 has been running fine since I did two things:
1) Upgraded to 10.0R3
2) Added a firewall rule to block incoming multicast traffic (because of what Oldtimer mentioned about multicast traffic traversing multiple interfaces)
It's been chugging along since the 9th. Unfortunately I can't say whether the multicast block or the upgrade fixed the problem, and I am loathe to disturb a 'stable' system to find out...
05-25-2010 05:28 AM
@KB_Fan, The DNS issue is PR #527294, where the DNS alg does not parse a compressed DNS response properly. The workaround is to disable the DNS alg and wait for 10.1R3 which will have the fix or get a special build from JTAC. In this case I will be waiting for the tested build.
@versello, so far so good. It hasn't locked up yet or cored flowd. I will post back if it happens again.
05-25-2010 06:26 PM
JTAC informed me 10.0S5.2 is out. URL: https://download.juniper.net/software/junos/regres
My IDP issues may be fixed in this release, but JTAC can't confirm it. I may upgrade my SRX650 later this week. I just applied it to my SRX210 without any problems.
05-31-2010 01:14 PM
SRX650 cluster running 10.0R3 + Webfiltering
Spent the weekended migrating our ISG to the SRX650s, they STOPPED this morning once some real load was put on them..
We have a ticket open with JTEC but rolled back to our ISG in the in term. Lets just say no one is very happy here today.
05-31-2010 06:40 PM - edited 05-31-2010 06:41 PM
For what it's worth my SRX has frozen a couple of times on 10.0R3 without any IDP features. At this point I'm rebooting it on a weekly basis to (hopefully) avoid downtime during operating hours.
06-17-2010 12:05 PM
Well our SRX650 cluster went back into production and failed a second time even with JTEC reviewing the config.. This time however we had them on live while it was down..
Turns out log rollover was NOT WORKING AT ALL.. The box just filled with logs and then died.. We cleared them, set tighter rollovers and they still exceeded the limits.
A work around is to set logging to almost nothing, but at this point it leaves us without traffic logs, which is a big problem.
we are running 10.0R3.10 still...
06-22-2010 09:29 AM
My SRX240 core dumped flowd again yesterday, no reasonable answer from JTAC yet as to why. The first recommendation was to update to 10.2R1 (which isn't even available yet), both PR# 's referenced by JTAC are supposedly fixed in the release that I am running, and also shouldn't apply to my box because of the configuration, so I don't think they are telling me the truth...
@mxk - Not happy with the SRX or JTAC at the moment. Most of the time when I talk to someone in India, I get the feeling that all they want to do is give an excuse to close the case so they will get their statistics up instead of actually solving the problem. Maybe Juniper management needs to look at how they are managing the support center as well as all the bugs in the SRX software? It might help get the bugs fixed faster at least, and maybe a little more customer satisfaction. Right now I don't think anyone who has bought an SRX branch series to use as a UTM device will ever buy another Juniper product.
06-23-2010 09:14 AM
The response I got from JTAC was that the issue was caused by "the synchronization between the flow daemon and IDP daemon" and they are working on scheduling a fix for 10.1R3.