static doesn't work

Answered Question
Sep 29th, 2007

I'm trying to do a simple scenario: accessing a server at the inside. I'm using the usual trio lines (static, acl, acg) as follow:

G= Global IP address (outside if)

F= Foreign IP address (origine of test)

access-list in_outside_static extended permit ip any host G.G.G.G

static (inside,outside) G.G.G.G 192.168.10.3 netmask 255.255.255.255

access-group in_outside_static in interface outside

But, it doesn't work...

The ACL is never fire up (hitcnt=0). But the log indicate:

TCP request discarded from F.F.F.F/1137 to outside:G.G.G.F/21.

Note: The outside interface receives his ip add by DHCP. Is static xlate has a problem with this?

Do you have an idea where to look to resolve this behavior.

I'm using a ASA 5520 version 7.2(1)

More info: I make a packet-tracer which reveals that G.G.G.G isn't translated in phase 2 below, why?

# packet-tracer input outside tcp F.F.F.F 1025 G.G.G.G$

Phase: 1

Type: FLOW-LOOKUP

Subtype:

Result: ALLOW

Config:

Additional Information:

Found no matching flow, creating a new flow

Phase: 2

Type: UN-NAT

Subtype: static

Result: ALLOW

Config:

static (inside,outside) tcp G.G.G.G ftp 192.168.10.3 ftp netmask 255.255.255.255 norandomseq

nat-control

match tcp inside host 192.168.10.3 eq 21 outside any

static translation to G.G.G.G/21

translate_hits = 0, untranslate_hits = 11

Additional Information:

NAT divert to egress interface inside

Untranslate G.G.G.G/21 to 192.168.10.3/21 using netmask 255.255.255.255

Phase: 3

Type: ROUTE-LOOKUP

Subtype: input

Result: ALLOW

Config:

Additional Information:

in G.G.G.G 255.255.255.255 identity

Phase: 4

Type: ACCESS-LIST

Subtype:

Result: DROP

Config:

Implicit Rule

Additional Information:

Result:

input-interface: outside

input-status: up

input-line-status: up

output-interface: NP Identity Ifc

output-status: up

output-line-status: up

Action: drop

Drop-reason: (acl-drop) Flow is denied by configured rule

Regards,

Ben

I have this problem too.
0 votes
Correct Answer by ajagadee about 9 years 2 months ago

Ben

Yes, this is by design. You must use the interface keyword instead of specifying the actual IP address when you want to include the IP address of a PIX Firewall interface in a static PAT entry.

Please refer the below command reference for details.

http://www.cisco.com/en/US/docs/security/pix/pix63/command/reference/s.html#wp1026694

I hope it helps.

Regards,

Arul

** Please rate all helpful posts **

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (3 ratings)
Loading.
acomiskey Sun, 09/30/2007 - 10:52

Change...

static (inside,outside) G.G.G.G 192.168.10.3 netmask 255.255.255.255

to...

static (inside,outside) interface 192.168.10.3 netmask 255.255.255.255

Please rate helpful posts.

bdube Sun, 09/30/2007 - 18:28

Thanks,

It was that. But G.G.G.G was the IP of the outside interface. At first hand, it looks similar but (interface) behave differently.

Do you have an explanation why "interface" behave differently of G.G.G.G, or is it just a feature by design?

Thanks for your help.

Ben

Correct Answer
ajagadee Sun, 09/30/2007 - 18:49

Ben

Yes, this is by design. You must use the interface keyword instead of specifying the actual IP address when you want to include the IP address of a PIX Firewall interface in a static PAT entry.

Please refer the below command reference for details.

http://www.cisco.com/en/US/docs/security/pix/pix63/command/reference/s.html#wp1026694

I hope it helps.

Regards,

Arul

** Please rate all helpful posts **

Actions

This Discussion