Port Redirection (Forwading) from Inside to Outside

Answered Question
Sep 17th, 2007
User Badges:

Dear All,


I have a requirement to configure a PIX.


It is a 515E with 6.3(5) software loaded.


We are connecting to a 3rd party via the Firewall.

It has 1 inside and 1 outside interface configured.


The requirement is that our internal hosts connect to a IP/Port combination on a Inside routable address and the PIX re-forwards the traffic to the outside host.


All documentation mentions configuring Outside (Internet) hosts so they can connect to a Outside IP/Port combination but not the reverse.


Why am I doing this?

Because the external 3rd party have a IP address range which were are not allowed to route internally.



Is this possible?


Any comments gratefully received!!


Correct Answer by Jon Marshall about 9 years 10 months ago

Oh for crying out loud :-)


Well done Craig, we were all so busy worrying about how to NAT a destination address that we completely overlooked the NAT on the source IP addresses !!


I should have spotted that and altho i don't want to speak for Sundar i think he will feel the same :)


Thanks for letting us know Craig


Jon

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (10 ratings)
Loading.
Jon Marshall Mon, 09/17/2007 - 05:15
User Badges:
  • Super Blue, 32500 points or more
  • Hall of Fame,

    Founding Member

  • Cisco Designated VIP,

    2017 LAN, WAN

Hi


inside routable address: 192.168.5.1

Outside address: 172.16.5.1


static (outside,inside) 192.168.5.1 172.16.5.1 netmask 255.255.255.255


You can add in ports into your static statement if you want to.


HTH


Jon

peskettc Mon, 09/17/2007 - 05:28
User Badges:

Hi Jon,


Thanks for your reply.


Can I ask,

How would the config line above create the re-direction?


If I have the following


Inside host 192.168.5.10

PIX Inside routable address: 192.168.5.1

PIX Outside address: 172.16.5.1

External Host of 172.16.5.2



But cannot use the 172.16.5.0 network or 0.0.0.0 in my routing tables.


Using Port Redirection in PIX you can connect to a pseudo outside address that is configured on the outside interface of the PIX which then (unknowing to the initiating host) reconnects to a internal machine.


I need this, but in reverse.


Jon Marshall Mon, 09/17/2007 - 05:36
User Badges:
  • Super Blue, 32500 points or more
  • Hall of Fame,

    Founding Member

  • Cisco Designated VIP,

    2017 LAN, WAN

Hi


We may be talking about different things here.


You need an address internally that routes to the pix inside interface. So lets say


inside interface of pix: 192.168.5.1

inside client: 192.168.5.10


You need an unused IP address from the 192.168.5.0/24 network eg 192.168.5.20


External host = 172.16.5.2


static (outside,inside) 192.168.5.20 172.16.5.2 netmask 255.255.255.255


You don't have to use 172.16.5.0 or 0.0.0.0 in your routing tables. Your 192.168.5.10 host just communicates with 192.168.5.20.


When the packet arrives at the pix internal interface the pix will translate the destination from 192.168.5.20 to 172.16.5.2 and then forward on to the external host.


If you don't have a spare address in your 192.168.5.0/24 network then you can use any address internally as long as it routes to the internal interface of the pix.


Does this make sense ?


Jon



peskettc Mon, 09/17/2007 - 06:29
User Badges:

Jon,


Thanks, with your assistance I am getting somewhere.


I have configured the line as above [substituting for my real addressing ;o) ], and am attempting a Telnet to the 192.168.5.20 address.


A show xlate does not display any translation occurring.

I have debug packet inside src 192.168.5.10


I can see packets being rec'd, as follows;

pixfirewall# --------- PACKET ---------


-- IP --

192.168.5.10 ==> 192.168.5.20


ver = 0x4 hlen = 0x5 tos = 0x0 tlen = 0x2c

id = 0x40b6 flags = 0x40 frag off=0x0

ttl = 0x78 proto=0x6 chksum = 0xdf9f


-- TCP --

source port = 0x1e81 dest port = 0x17syn


seq = 0xce871757

ack = 0x0

hlen = 0x6 window = 0xffff

checksum = 0xb19d urg = 0x0

tcp options:

0x2 0x4 0x5 0x50 -- DATA --

00000020: 00 00 41 |

..A


--------- END OF PACKET ---------



I have also run the command;

debug packet outside


But I can see no traffic exiting the outside of the PIX.


Is there any other debug commands I can use or tips?


Thanks again,

Craig.

Jon Marshall Mon, 09/17/2007 - 06:39
User Badges:
  • Super Blue, 32500 points or more
  • Hall of Fame,

    Founding Member

  • Cisco Designated VIP,

    2017 LAN, WAN

Hi Craig


Can you check the following


1) You have a route to the remote network ( the real address )

2) You are allowing the traffic out if you have an access-list applied on the inside interface.


Jon

peskettc Mon, 09/17/2007 - 08:02
User Badges:

Hi Jon,


Re: 1)

I have a route outside configured (ping from the PIX is successful confirming IP connectivity OK)


Re 2)

I have a access-list that is current set to permit ip any any (on inside and outside interfaces ) [for initial testing purposes].

Plus packets are reaching the PIX and is confirmed by the previous debug).




I can see packets arriving on the internal interface as per my last post but the XLATE function is not pickup up the traffic.


I have attempted ;

show xlate

show xlate inside

show xlate outside

show xlate debug

--Which show nothing..





Are there any other suggestions ideas on this one?


Jon Marshall Mon, 09/17/2007 - 09:00
User Badges:
  • Super Blue, 32500 points or more
  • Hall of Fame,

    Founding Member

  • Cisco Designated VIP,

    2017 LAN, WAN

Hi


Can you post a sanitised copy of config. I have used this command many times in our environment so i know it should work.


Jon

sundar.palaniappan Mon, 09/17/2007 - 16:20
User Badges:
  • Green, 3000 points or more

Craig,


Agree with Jon the static should work.


Let's say you have the following setup.


inside host: 192.168.1.10

outside host: 172.16.1.2

inside destination to get to the outside host: 192.168.1.20


static (outside,inside) 192.168.1.20 172.16.1.2 netmask 255.255.255.255


Any traffic initiated from inside to 192.168.1.20 the PIX will redirect it to the outside host address of 172.16.1.2. Does the outside host know how to route to your inside network?


HTH


Sundar

peskettc Tue, 09/18/2007 - 05:35
User Badges:

Hi Jon/Sundar,


Here you go...




********************

********************

: Saved

:

PIX Version 6.3(5)

interface ethernet0 auto

interface ethernet1 auto

interface ethernet2 auto shutdown

interface ethernet3 auto shutdown

interface ethernet4 auto shutdown

interface ethernet5 auto shutdown

nameif ethernet0 outside security0

nameif ethernet1 inside security100

nameif ethernet2 faillink security30

nameif ethernet3 intf3 security6

nameif ethernet4 intf4 security8

nameif ethernet5 intf5 security10

enable password xx encrypted

passwd xx encrypted

hostname pixfirewall

domain-name xx.com

fixup protocol dns maximum-length 512

fixup protocol ftp 21

fixup protocol h323 h225 1720

fixup protocol h323 ras 1718-1719

fixup protocol http 80

fixup protocol rsh 514

fixup protocol rtsp 554

fixup protocol sip 5060

fixup protocol sip udp 5060

fixup protocol skinny 2000

fixup protocol smtp 25

fixup protocol sqlnet 1521

fixup protocol tftp 69

names

access-list 150 permit ip any any

pager lines 24

logging timestamp

logging console debugging

logging buffered debugging

mtu outside 1500

mtu inside 1500

mtu faillink 1500

mtu intf3 1500

mtu intf4 1500

mtu intf5 1500

ip address outside 172.16.5.2 255.255.255.0

ip address inside 192.168.5.1 255.255.255.0

no ip address faillink

no ip address intf3

no ip address intf4

no ip address intf5

ip audit info action alarm

ip audit attack action alarm

no failover

failover timeout 0:00:00

failover poll 15

no failover ip address outside

no failover ip address inside

no failover ip address faillink

no failover ip address intf3

no failover ip address intf4

no failover ip address intf5

pdm history enable

arp timeout 14400

static (outside,inside) 192.168.5.20 172.16.5.2 netmask 255.255.255.255 0 0

access-group 150 in interface outside

access-group 150 in interface inside

route outside 0.0.0.0 0.0.0.0 172.16.5.254 1

route inside 192.168.5.0 255.255.255.0 155.30.3.253 1

timeout xlate 3: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 sip-disconnect 0:02:00 sip-invite 0:03:00

timeout uauth 0:05:00 absolute

aaa-server TACACS+ protocol tacacs+

aaa-server TACACS+ max-failed-attempts 3

aaa-server TACACS+ deadtime 10

aaa-server RADIUS protocol radius

aaa-server RADIUS max-failed-attempts 3

aaa-server RADIUS deadtime 10

aaa-server LOCAL protocol local

ntp server x.x.x.x source inside

no snmp-server location

no snmp-server contact

snmp-server community public

no snmp-server enable traps

floodguard enable

telnet 0.0.0.0 0.0.0.0 inside

telnet timeout 5

ssh timeout 5

console timeout 0

terminal width 80

: end

pixfirewall#

********************

********************


Jon Marshall Tue, 09/18/2007 - 05:55
User Badges:
  • Super Blue, 32500 points or more
  • Hall of Fame,

    Founding Member

  • Cisco Designated VIP,

    2017 LAN, WAN

Craig


static (outside,inside) 192.168.5.20 172.16.5.2 netmask 255.255.255.255 0 0


172.16.5.2 is the address attached to your outside interface on the pix. You need to change this to be the host you are trying to get to eg if the actual address of the host you are trying to get to is 172.16.5.10


static (outside,inside) 192.168.5.20 172.16.5.10 netmask 255.255.255.255


Jon

peskettc Tue, 09/18/2007 - 07:01
User Badges:

DARN!!


static (outside,inside) 192.168.5.20 172.16.5.10 netmask 255.255.255.255


That is how it is configured.

Its my mistake whilst I was sanitizing the config.


I guess we are out of ideas, the config is correct but I cannot seem to get traffic to work.


If I telnet to 192.168.5.20 I see Syn's from the originating machine sent to the PIX but no replies.

Also 'debug packet inside' shows the syn's arriving on the inside interface.


But, the traffic is not being NAT xlate'd..



Stuck...

:o(

peskettc Tue, 09/18/2007 - 07:27
User Badges:

pixfirewall# --------- PACKET ---------


-- IP --

192.168.5.10 ==> 192.168.5.20


ver = 0x4 hlen = 0x5 tos = 0x0 tlen = 0x2c

id = 0xb57c flags = 0x40 frag off=0x0

ttl = 0x79 proto=0x6 chksum = 0x69da


-- TCP --

source port = 0x607d dest port = 0x17syn


seq = 0xbd3d6408

ack = 0x0

hlen = 0x6 window = 0xffff

checksum = 0x343b urg = 0x0

tcp options:

0x2 0x4 0x5 0x50 -- DATA --

00000020: 00 00 41 |

..A


--------- END OF PACKET ---------



pixfirewall#



sho debug

debug access-list all

debug fixup tcp

debug packet outside both

debug packet inside src 192.168.5.10 both



pixfirewall#


Adding

debug icmp trace


Then pinging the Inside NAT ip


Show the following on the console;


ICMP echo-request from inside:192.168.5.10 to 192.168.5.20 ID=512 seq=4608 length=40

ICMP echo-request from inside:192.168.5.10 to 192.168.5.20 ID=512 seq=4864 length=40

ICMP echo-request from inside:192.168.5.10 to 192.168.5.20 ID=512 seq=5120 length=40

ICMP echo-request from inside:192.168.5.10 to 192.168.5.20 ID=512 seq=5376 length=40



But no XLATE is being created.


pixfirewall# sho xlate debug

0 in use, 0 most used

Flags: D - DNS, d - dump, I - identity, i - inside, n - no random,

o - outside, r - portmap, s - static

pixfirewall#

Jon Marshall Tue, 09/18/2007 - 09:41
User Badges:
  • Super Blue, 32500 points or more
  • Hall of Fame,

    Founding Member

  • Cisco Designated VIP,

    2017 LAN, WAN

Craig


Okay, i think i know the problem. The NAT order of operation for the pix from inside interface to outside is to route first then NAT. I think the problem is that we have used an address out of the same subnet as the pix inside interface.


This would work fine on the outside interface because it NAT's first then routes.


I have used the config i supplied many times but what i never did now i come to think of it is to use an ip address out of the same subnet as the pix internal interface.


So would it be possible to do this


1) Use a private address that does not currently exist on your internal network and does not conflict with your remote partner.


eg 192.168.10.1


2) You now need to ensure that any traffic destined for 192.168.10.1 goes to the pix internal interface. Note that if the default gateway set on on your client 192.168.5.10 is the pix then you will be fine.


3) Change the static statement to


static (outside,inside) 192.168.10.1 172.16.5.10 netmask 255.255.255.255


Then make the connection from 192.168.5.10 to 192.168.10.1


I believe this will now work. Apologies for misleading you before, i forgot the NAT order of operation from inside to outside.


Please let me know how you get on


Jon

sundar.palaniappan Tue, 09/18/2007 - 13:03
User Badges:
  • Green, 3000 points or more

Jon,


It just works fine in my lab with the same setup that Craig has. It's a PIX515E running 7.2.2


Existing Configuration:


PIX515E(config)# show run static

static (outside,inside) 192.168.5.20 172.16.5.10 netmask 255.255.255.255

PIX515E(config)# show xlate1 in use, 1 most used

Global 192.168.5.20 Local 172.16.5.10

PIX515E(config)# show access-list acl_outside

access-list acl_outside; 1 elements

access-list acl_outside line 1 extended permit icmp host 172.16.5.10 host 192.168.5.10 echo-reply (hitcnt=0) 0x9c61191a

PIX515E(config)# show run access-group

access-group acl_outside in interface outside


Pinged 192.168.5.20 from inside host 192.168.5.10 and echo replies.


PIX515E(config)# show access-list acl_outside

access-list acl_outside; 1 elements

access-list acl_outside line 1 extended permit icmp host 172.16.5.10 host 192.168.5.10 echo-reply (hitcnt=1) 0x9c61191a --> Return traffic matches.


Craig,


Can you verify the outside host (172.16.5.10) routes the traffic destined to 192.168.5.10 to the PIX outside interface (172.16.5.2).


HTH


Sundar

Jon Marshall Tue, 09/18/2007 - 13:11
User Badges:
  • Super Blue, 32500 points or more
  • Hall of Fame,

    Founding Member

  • Cisco Designated VIP,

    2017 LAN, WAN

Hi Sundar


Didn't have access to a firewall to test so wasn't sure why it was not working for Craig.


Can you confirm that the inside IP address of the pix is in the 192.168.5.x range ? If so then it looks like it should work after all. As i say i have always used a separate subnet for this sort of thing from inside to outside.


Thanks for testing this out Sundar.


Jon

sundar.palaniappan Tue, 09/18/2007 - 14:29
User Badges:
  • Green, 3000 points or more

Not a problem Jon.


The inside host address is 192.168.5.10 and that's the same subnet as inside interface of the PIX itself. Actually, I configured two routers to be inside/outside host and enabled ICMP debugs on the outside router to make sure it wasn't the PIX that was sending proxy ARP replies to the inside host.


I am starting to wonder whether Craig may have to enable proxy ARP on the inside interface for this to work. I guess it wouldn't be a bad idea to try configuring 'no sysopt noproxyarp inside' and test.


HTH


Sundar

peskettc Wed, 09/19/2007 - 03:35
User Badges:

Sundar / Jon,


Once again, a big thank-you for your continued support - it is most appreciated.


I am running a 515e but with 6.3(5) software - so your lab is not using the same code.

Could there be a difference in NAT Order of Operation between 6.x and 7.x?


As this is in a remote site (in Africa) sadly there is no Infrastructure to create another VLAN & IP address range.


Is there a way to disable IP routing?


If the packets are arriving at the PIX and displayed by debug packet then I assume Proxy ARP is working correctly.?

peskettc Wed, 09/19/2007 - 09:19
User Badges:

Fixed!!



The following lines were required;

global (outside) 1 interface

nat (inside) 1 0.0.0.0 0.0.0.0 0 0

Correct Answer
Jon Marshall Wed, 09/19/2007 - 09:29
User Badges:
  • Super Blue, 32500 points or more
  • Hall of Fame,

    Founding Member

  • Cisco Designated VIP,

    2017 LAN, WAN

Oh for crying out loud :-)


Well done Craig, we were all so busy worrying about how to NAT a destination address that we completely overlooked the NAT on the source IP addresses !!


I should have spotted that and altho i don't want to speak for Sundar i think he will feel the same :)


Thanks for letting us know Craig


Jon

networking11 Thu, 09/27/2007 - 22:47
User Badges:

hai, your issue is of great useful to my project consideration

Actions

This Discussion