cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
277
Views
3
Helpful
2
Replies

wrong translation slot

bbanier
Level 1
Level 1

Hello all,

I got a problem with a PIX515E, Cisco PIX Firewall Version 6.3(1)

Cisco PIX Device Manager Version 3.0(1):

there are 3 networks involved: outside, DMZ, net3

- security levels: outside=0, DMZ=60, net3=80

- from both outside and DMZ, I need to go to a smtp-server that is reachable via the interface on net3

- from outside it is ok, from DMZ it is not (so the route to the smtp server is ok)

- the access-lists are the same (except for interface and source IPs of course)

- no translations need to be done, configured the same

- this is what I see in the logs when I try to connect from DMZ to the smtp-server:

%PIX-6-305009: Built static translation from net3:IP3 to outside:IP3

instead of the expected "%PIX-6-305009: Built static translation from net3:IP3 to DMZ:IP3

and:

%PIX-6-302013: Built inbound TCP connection 22996564 for DMZ:IPDMZ/2326 (IPDMZ/2326) to net3:IP3/25 (IP3/25)

%PIX-4-106023: Deny tcp src net3:IP3/25 dst DMZ:IPDMZ/2326 by access-group "net3-in"

Captured traffic:

IPDMZ.1871 > IP3.25: S 2792848283:2792848283(0) win 65535 <mss 1380,nop,nop,sackOK>

IP3.25 > IPDMZ.1871: S 1669425112:1669425112(0) ack 2792848284 win 65535 <mss 1460,nop,nop,sackOK>

IPDMZ.1871 > IP3.25: R 2792848284:2792848284(0) ack 1669425113 win 65535 <mss 1460,nop,nop,sackOK>

- arp entries are ok; a clear xlate doesn't solve the problem

What is strange also, is that I had the same config in but with a different IP address for the smtp-server, which worked. The only difference now is that the IP of the smtp-server has changed...

Anyone seen this before ? Any tips ?

Thanks for any help !

2 Replies 2

nkhawaja
Cisco Employee
Cisco Employee

Hi,

This is what the problem is

%PIX-4-106023: Deny tcp src net3:IP3/25 dst DMZ:IPDMZ/2326 by access-group "net3-in"

We need to see the configs...

Thanks

Nadeem

Hello,

this is some more info on the config; due to customer confidentiality, I needed to rework it a bit, and state only the lines related to this problem. This extract should be enough though, I think, as there are no deny-statements anywhere. So, I ‘ld expect the firewall to accept the request to connect to the smtp-server, and following that, allow all return-traffic for this same connection back in, as it is stateful ?!

There is no rule that permits setting up SMTP-traffiek from net3 towards the networks “DMZ” or ”outside”, but this is intended: we only want people to set up connections towards the SMTP-server, and not in the other direction.

(one can see from the captured traffic that no new connection is set up anyway.)

interface ethernet0 100full

interface ethernet2 100full

interface ethernet3 100full

nameif ethernet0 outside security0

nameif ethernet2 net3 security80

nameif ethernet3 DMZ security60

fixup protocol ftp 21

no fixup protocol h323 h225 1720

no fixup protocol h323 ras 1718-1719

fixup protocol http 80

no fixup protocol ils 389

no fixup protocol rsh 514

no fixup protocol rtsp 554

no fixup protocol sip 5060

no fixup protocol sip udp 5060

no fixup protocol skinny 2000

fixup protocol smtp 25

no fixup protocol sqlnet 1521

access-list outside-in permit tcp object-group outside-hosts host smtp-server eq smtp

access-list net3-in : there is no deny-statement in this list, only permits

access-list DMZ-in permit tcp object-group DMZ-hosts host smtp-server eq smtp

mtu outside 1500

mtu net3 1500

mtu DMZ 1500

nat (inside) 0 0.0.0.0 0.0.0.0 0 0

nat (net3) 0 0.0.0.0 0.0.0.0 0 0

nat (DMZ) 0 0.0.0.0 0.0.0.0 0 0

static (net3,outside) 192.168.3.0 192.168.3.0 netmask 255.255.255.0 0 0

static (net3,DMZ) 192.168.3.0 192.168.3.0 netmask 255.255.255.0 0 0

access-group outside-in in interface outside

access-group net3-in in interface net3

access-group DMZ-in in interface DMZ

route net3 192.168.3.0 255.255.255.0 gw-to-192.168.3.0

timeout xlate 1:00:00

timeout conn 1:00:00 half-closed 0:10:00 udp 0:02:00 rpc 0:10:00 h225 1:00:00

timeout h323 0:05:00 mgcp 0:05:00 sip 0:30:00 sip_media 0:02:00

timeout uauth 0:05:00 absolute

thanks,

Bart