I have a PIX 515 6.3 and I want to have the LAN behind a DMZ to access the servers on the inside LAN and also the remote hosts which are routed on a L3 switch.
This is what I did :
nat (DMZ) 4 192.168.4.0 255.255.255.0 outside 0 0
global (inside) 4 172.16.10.10
access-list DMZ-TEST permit ip 192.168.4.0 255.255.255.0 any
And it does not work.
I get back " No transaltion group found".
This is the PIX:
Cisco PIX Firewall Version 6.3(4)
nameif ethernet1 inside security100
nameif ethernet2 DMZ security20
Thanks for the help!
On the pix due to security levels, it is mandatory to have a static translation when coming from a lower security interface (dmz 20) to a higher security interface (inside 100) you need to define a static like:
static (inside,outside) X.X.X.X Y.Y.Y.Y where X.X.X.X is the address that you are natting your internal server/network and Y.Y.Y.Y is the real ip for that server/network
" it is mandatory to have a static translation when coming from a lower security interface (dmz 20) to a higher security interface (inside 100)"
Not sure it is. I have configured the following many times
nat (outside) 1 192.168.5.0 255.255.255.0 outside
global (inside) 1 18.104.22.168
where all source addresses of 192.168.5.x coming in from the outside will be translated to 22.214.171.124.
Is this not a supported configuration ?
I thought the same, then I did the static translation and it still didnt work.
And anyway , if I have 100 servers and 30 networks to access I have to do all those statics.
Sounds a bit absurd.
I was checking some documents on cisco, and there was mentioned that this configuration should work.
It definately works with ASA.
the keyword outside at the end allows the traffic from lower sec to higher security.
My problem is that I get" No transaltion group found "
The only difference between your config and the one i have used many times before is the fact that your lower security interface is the DMZ interface and not the outside interface but looking at the command reference for 6.3 it only talks about lower to higher and having to use the "outside" keyword ie. it doesn't say it has to be specifically the outside interface.
Unfortunately i don't have a pix to test with so am of limited help but as previously discussed i know this works outside -> inside.
It definetly works with 7.0, but it says it was introduced with 6.2 so it should work with mine as well.
I dont really understand why ...? Could it be a bug in the IOS ...is there anybody aware of this?
A bit of help here people,c'mon!
Does the interface name have to be outside...I mean I dont think so, sounds a bit ...
I suppose it reffers to traffic from lower to higher ...not specifically outside---> inside.
Thanks for your help!
"Does the interface name have to be outside" - well that's what i have done before but as i say the command reference for 6.3 suggests it just has to be a lower security interface. Could you run a quick test with outside or is this not possible ?
I can guarantee it works on 6.x because that was the version of code i used this configuration on.
This is a test fw , so yes I will try with the outside interface tomorrow and let you know the result ,but if this would be succesful then where is the point of having this feature if it does not work with the rest of the interfaces as well?
Okay, let me know what happens.
"but if this would be succesful then where is the point of having this feature if it does not work with the rest of the interfaces as well?"
Can't answer that unfortunately - leave that one to Cisco i think :-)
Just did this and guess what : " NO translation group found".
This is the config :
ccess-list acl-in permit ip any any
access-list acl-in permit icmp any any
access-list out permit ip any any
access-list out permit icmp any any
pager lines 24
logging monitor informational
logging buffered informational
mtu outside 1500
mtu inside 1500
ip address outside 192.168.4.1 255.255.255.0
ip address inside 10.10.10.1 255.255.255.0
ip audit info action alarm
ip audit attack action alarm
pdm history enable
arp timeout 14400
global (inside) 1 interface
nat (outside) 1 192.168.4.0 255.255.255.0 outside 0 0
access-group out in interface outside
access-group acl-in in interface inside
Do you have a hammer you could use on the pix ...
Just found this bug -
CSCee85940 Bug Details Bug #18 of 289 | < Previous | Next >
outside nat not working
Symptom: "outside nat" configured using nat and global statements is not working.
Conditions: When traffic is initiated from low security interface side, source nating or bidirectional nating
Workaround: Use static nat for source nat or bidirectional nat
Now it says it's fixed in 6.3(4) but at the same time it says it is first found in 6.3(4). Any chance you could ugrade to 6.3(5) and retest ?
I thought about a bug also and the confiuration pasted here is from a 6.3(5) and it does not work.
So , I think the hammer is the ultimate solution in solving this.
TNT would be more fun. I don't see why ANYONE would buy an ASA. What a POS. Object tracking blows, Nat0 BS blows. No route map capability and it is F*ing SLOOOOOW. Get a router - you cant lose!