| Author |
Firewall NAT Rule Problem
|
|
| btroadman 2003-11-12, 11:34 am |
| I have a PIX 525 with many interfaces. Many NAT and Access rules, no real problems at all. I am trying to bring the 7th interface online (UR License by the way). It connects to another entity.
I can create a PAT for the new interface and can connect to devices on the other end of the PIX just fine. But as soon as I take an internal device and create a seperate NAT rule for it, that single device can no longer connect to the other side of the firewall interface.
Can someone please offer any ideas? I see no syslog errors when connections are attempted. It is acting like it works just fine, but does not work at all. I know you guys are probably thinking it could be a dozen things. But everything checks out OK.
Thank You. | |
| btroadman 2003-11-12, 2:54 pm |
| Just a little bit more info. I am constantly getting a
"Deny UDP reverse path check from src 10.53.x.x to 10.52.255.255" on interface inside"
Just so happens that the 10.53.x.x is the other side of the interface I am trying to get connected. Now I did my research and tried turning of the antispoofing on the internal interface and get stuck with these messages instead...
"portmap translation creation failed for udp src inside 10.53.x.x/137 dst INTERFACE:10.53.255.255/137"
Someone please enlighten me. This was a bad week to try and stop using profanity. HELP PLEASE! | |
| btroadman 2003-11-14, 7:37 am |
| I found the solutions, the problem with the translations was that the genius that was here before me had Proxy ARPs turned off on that interface. And now I am kicking myself for not finding it sooner. It was pretty blatant after all.....makes me realize I better keep studying.
The problem with the traffic originating from the inside interface that shouldn't have been coming from there. Well that is simple too. You see the entitiy that plugs into that 7th interface of the firewall is VLAN'ed over through 9 different switches. Which is normal, but what isn't normal is setting up a PortChannel for that VLAN in the core router.
This is now my 6th day on this new job, I hope I don't find any more issues like what has been going on here lately.
And for you firewall GURU's out there I'd like to share one other tidbit that the jacka$$ before me did. We got hit with the Welchia (1800 users with unpatched workstations, I wonder why). And the genius had a rule letting "echo" icmp go outbound. And I wonder why my edge router wasn't responding.
Can someone share a good link for CiscoWorks 2000, I think it is my only hope of survival. | |
| bloodshotx 2003-11-14, 11:53 am |
| we have been fighting the nachi.worm for the last 3 days.
We have 800 systems not using windows update services and our firewall allowed outbound and inbound icmp traffic (pings)..
So basicly it infected every machine and ping flooded the network.
Our main switch is a 4006 and we have about 15 vlans running on it. | |
| darthfeces 2003-11-14, 1:20 pm |
| sounds like you walked into a security nightmare.
you'll have to learn the crappy network before you make changes.
sometimes i make this mistake.
when you make changes that are best practice
they can break the crappy setup.
peronally i'd grab copies of all switch and router configs and print them out.
you could be a ccie and not be able to
understand someone's crapppy setup straight away. bad design is bad design.
your task is to incrementally secure that network without them even knowing it.
the hardest thing of all will be
getting then to unbderstand the word no ....
balancing ease of use vs security.
http://www.cisco.com/warp/customer/...4-blaster.shtml
http://www.cisco.com/warp/public/70...820-nachi.shtml | |
| btroadman 2003-11-14, 1:39 pm |
| Luckily at my last job we got hit with the Nachi/Welchia so I knew how to take care of it easier. First I hope you killed those ICMP rules straight away. I used KixStart and ran the Microsoft Patch in silent mode, and the Stinger.exe from McAfee in silent mode and just scanned the c:\%systemroot%\system32 directory. Login script ran for a minute or two, and that took care of them. Some of the stragglers just hit through SMS or had the helpdesk do them manually.
If you have windump or tcpdump this might help.....
tcpdump -qn dst port 135 or 4444 or 69
tcpdump -qn icmp and ip[40] = 0xaa
As far as the crappy network here, it isn't really too horribly bad, just a bunch of little stuff so far that has screwed me. And of course I am trying to figure out where everything is at. 1800 users across 20+ locations is not what I am used to. I brought CiscoWorks 2000 online and it found 60 some odd devices, with no Visio Diagrams it makes it difficult. There is only 1 other Network Engineer who isn't really that helpful as of yet. I would settle for someone who knew where stuff was at this point. | |
| darthfeces 2003-11-14, 2:06 pm |
| e-eye retina also has a nice free dcom vulnerabilty scanner.
time to find the unpatched buggers .....
http://www.eeye.com/html/Research/Tools/RPCDCOM.html
oh
and as secure as i claim my network to be
all it took was 1 dialup or laptop user to
bring it in here and 30 non-patching bozo's and .......... icmp hell !!!!
only internallly though icmp can't get in and echo-reply's can't come back unless there's a static and conduit. | |
| btroadman 2003-11-14, 3:53 pm |
| Yeah, they currently have an SUS server installed on the network, but no one bothered to make sure machines had XP SP1 or 2000 SP3 on them, so half of the users got the Welchia....AT LEAST. I have a feeling it came from the RRAS server here too, but that will be almost impossible to prove.
After I found that echo outbound rule (Please explain to me why that would be there) I at least got the Firewall working properly, from there it was more of an annoyance than anything else. Cluttering up my firewall logs. If anything it has put my CCIE studying behind. |
|
|
|