cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1219
Views
45
Helpful
20
Replies

Port Redirection (Forwading) from Inside to Outside

peskettc
Level 1
Level 1

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!!

1 Accepted Solution

Accepted Solutions

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

View solution in original post

20 Replies 20

Jon Marshall
Hall of Fame
Hall of Fame

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

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.

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

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.

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

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?

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

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

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#

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

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

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

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(

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#

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

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

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: