Still celebrating National IT Professionals Day with 3 months of free Premium Membership. Use Code ITDAY17

x
?
Solved

PIX 506: Have a static IP address that needs to route into internal network when requested

Posted on 2006-10-30
18
Medium Priority
?
1,095 Views
Last Modified: 2013-11-16
I'm working on a network with a web server where the whole network uses a static IP address that has port 80 forwarded to the web server.  Users outside the network can get to the web server - no problems.  Users inside the network can't.  How do I configure the PIX 506 to route the traffic going out looking for the server at the IP address to come back into the network to the web server?
0
Comment
Question by:stev0931
[X]
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
18 Comments
 
LVL 20

Accepted Solution

by:
calvinetter earned 840 total points
ID: 17840012
A PIX won't allow you to directly access the public IP that's statically NAt'd to the IP of an internal server, that's by design.  But, you have 2 options for some DNS trickery:
  1) If your internal workstations use an internal DNS server for all their DNS resolution, you can add an entry for your web server's public hostname, eg "www.externaldomain.com" to point to the internal IP.
  2) If DNS resolution for "www.externaldomain.com" is handled by external DNS servers (eg, your ISP) that are *outside* the PIX, then you can do some DNS trickery on the PIX, which makes the PIX provide the inside hosts w/ the internal IP of the web server when they request "www.externaldomain.com".
  Example:
no nat (inside) 1 0.0.0.0 0.0.0.0   <- temporarily remove NAT
no static (inside,outside) tcp 4.3.2.1 http 192.168.1.5 http  <- temporarily remove static NAT entry for web server
clear xlate   <- very important! clears the NAT table

nat (inside) 1 0.0.0.0 0.0.0.0 dns   <- re-add NAT w/ 'dns' keyword
static (inside,outside) tcp 4.3.2.1 http 192.168.1.5 http dns   <- re-add static NAT entry w/ 'dns' keyword
clear xlate

cheers
0
 

Author Comment

by:stev0931
ID: 17840104
On my Linksys router, I could set up a static route they called it.  So, you're saying there's no such equiv. on the PIX?
0
 
LVL 2

Assisted Solution

by:sscuser
sscuser earned 80 total points
ID: 17842335
That's called hairpinning in Cisco terminology, when traffic is sent outbound then is sent back within the PIX itself.  The PIX does not support this by design.

I would recommend just using an alternate DNS entry internally for your web server and have your internal users use that....ie outside users use www.externaldomain.com and internal users use www.internaldomain.com

Just another option...


0
NFR key for Veeam Agent for Linux

Veeam is happy to provide a free NFR license for one year.  It allows for the non‑production use and valid for five workstations and two servers. Veeam Agent for Linux is a simple backup tool for your Linux installations, both on‑premises and in the public cloud.

 
LVL 3

Assisted Solution

by:mahe2000
mahe2000 earned 80 total points
ID: 17842514
you need an internal dns for your users with the same external domain but with the internal IP addresses and you have to make him ask other dns when you want to resolve other external addresses. all your internal users should use this internal dns for resolution.
0
 

Author Comment

by:stev0931
ID: 17842751
Just out of curiosity: Is there a way to catch the packet on the inside interface before it goes outside and sent it back on the inside interface to the correct IP?  I'm assuming not from what you said, but it's at least worth asking...
0
 

Author Comment

by:stev0931
ID: 17846314
calvinetter,

Your option 2 looks like what I need to do.  So, just to clarify, if I type in the commands you gave in your example, a computer at 192.168.1.212 that wants to go to www.xyz.com (the server at 192.168.1.5), this is what will happen:
DNS request made to 8.7.6.5, response of 4.3.2.1 comes back
The PIX sees the response and changes the 4.3.2.1 to 192.168.1.5
192.168.1.212 connects to 192.168.1.5
(problem solved)

Did I get this right?
0
 
LVL 20

Assisted Solution

by:calvinetter
calvinetter earned 840 total points
ID: 17847192
>(sscuser) That's called hairpinning in Cisco terminology...  The PIX does not support this by design.
    Right, PIX 6.x or below doesn't, but 7.x actually does.  BUT, 7.x code is only supported on PIX 515 & above, so no joy w/ a 506!

>just out of curiosity: Is there a way to catch the packet on the inside interface....
   Nope, that's the same as 'hairpinning' like sscuser mentioned.  PIX software 6.x & below security algorithm won't allow traffic to enter & exit the same interface (which is what a router or PIX 7.x would allow).

>DNS request made to 8.7.6.5, response of 4.3.2.1 comes back
>The PIX sees the response and changes the 4.3.2.1 to 192.168.1.5
   Exactly!  (If 4.3.2.1 is the public IP for www.xyz.com, & 8.7.6.5 is a DNS server outside your PIX).

As I mentioned initally (& mahe2000 also agreed) you could put an entry on your local DNS server(s)...whatever's easier & more convenient for you.  The PIX method is easy enough.

cheers
0
 

Author Comment

by:stev0931
ID: 17847490
Excellent!  

So one last question: I have a bunch of access-lists and statics set up to forward ports.  I'm assuming I will need to remove all my statics before executing the commands and then I'll have to re-create them after.  I'm also assuming that the access-lists won't need to be messed with (or anything else).  Is this correct?
0
 
LVL 20

Assisted Solution

by:calvinetter
calvinetter earned 840 total points
ID: 17847542
>I'm assuming I will need to remove all my statics before executing the commands...
   You'll need to remove/change the "nat (inside) 1 0.0.0.0..." statement, yes.  For the statics, you'll really only need to modify whatever's referencing the web server's IP.  Yes, you'll positively need to remove any current static entries first, or the PIX will complain about duplicate entries.

And no, you won't have to mess w/ ACLs (access-lists) at all.

cheers
0
 

Author Comment

by:stev0931
ID: 17847668
I just went through all these steps, but it didn't work.  The commands executed successfully, but it hasn't solved the problem...  Any thoughts?
0
 
LVL 20

Assisted Solution

by:calvinetter
calvinetter earned 840 total points
ID: 17847690
Run 'clear xlate' once again & retry.  If still having problems, please post your complete but sanitized config (passwords removed, public IPs masked like so: x.x.2.1, all other IP info intact).

cheers
0
 

Author Comment

by:stev0931
ID: 17850765
Tried the clear xlate - no luck - so here's a sh run...


: Saved
:
PIX Version 6.3(1)
interface ethernet0 10full
interface ethernet1 10full
nameif ethernet0 outside security0
nameif ethernet1 inside security100
enable password XXXXXXXXXXXXXXX encrypted
passwd XXXXXXXXXXXXXXX encrypted
hostname XXXXXXXX
domain-name XXXXXXXXXXX
fixup protocol ftp 21
fixup protocol h323 h225 1720
fixup protocol h323 ras 1718-1719
fixup protocol http 80
fixup protocol ils 389
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
names
access-list inside_access_in permit icmp any any
access-list inside_access_in permit ip any any
access-list outside_access_in permit icmp any any
access-list outside_access_in permit tcp any host X.X.233.55 eq www
access-list outside_access_in permit tcp any interface outside eq smtp
access-list outside_access_in permit tcp any interface outside eq 13389
access-list outside_access_in permit tcp any interface outside eq 23389
access-list outside_access_in permit tcp any interface outside eq 444
access-list outside_access_in permit tcp any interface outside eq 888
access-list outside_access_in permit tcp any interface outside eq 5500
access-list outside_access_in permit tcp any interface outside eq 5900
access-list outside_access_in permit tcp any interface outside eq 3000
access-list outside_access_in permit tcp any interface outside eq 3001
access-list outside_access_in permit tcp any interface outside eq https
pager lines 24
icmp deny any outside
icmp permit any inside
mtu outside 1500
mtu inside 1500
ip address outside X.X.233.55 255.255.252.0
ip address inside 192.168.1.1 255.255.255.0
ip audit info action alarm
ip audit attack action alarm
pdm logging informational 100
pdm history enable
arp timeout 14400
global (outside) 1 interface
nat (inside) 1 0.0.0.0 0.0.0.0 dns 0 0
static (inside,outside) tcp X.X.233.55 www 192.168.1.100 www netmask 255.255.255.255 0 0
static (inside,outside) tcp X.X.233.55 smtp 192.168.1.100 smtp netmask 255.255.255.255 0 0
static (inside,outside) tcp X.X.233.55 3000 192.168.1.203 3000 netmask 255.255.255.255 0 0
static (inside,outside) tcp X.X.233.55 3001 192.168.1.203 3001 netmask 255.255.255.255 0 0
static (inside,outside) tcp X.X.233.55 444 192.168.1.100 444 netmask 255.255.255.255 0 0
static (inside,outside) tcp X.X.233.55 888 192.168.1.100 888 netmask 255.255.255.255 0 0
static (inside,outside) tcp X.X.233.55 13389 192.168.1.100 13389 netmask 255.255.255.255 0 0
static (inside,outside) tcp X.X.233.55 23389 192.168.1.100 23389 netmask 255.255.255.255 0 0
static (inside,outside) tcp X.X.233.55 5500 192.168.1.100 5500 netmask 255.255.255.255 0 0
static (inside,outside) tcp X.X.233.55 https 192.168.1.100 https netmask 255.255.255.255 0 0
access-group outside_access_in in interface outside
access-group inside_access_in in interface inside
route outside 0.0.0.0 0.0.0.0 X.X.232.1 1
timeout xlate 0:05: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
aaa-server TACACS+ protocol tacacs+
aaa-server RADIUS protocol radius
aaa-server LOCAL protocol local
http server enable
http 192.168.1.0 255.255.255.0 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 0.0.0.0 0.0.0.0 inside
ssh timeout 20
console timeout 0
dhcpd address 192.168.1.150-192.168.1.188 inside
dhcpd dns X.X.224.1 X.X.224.3
dhcpd lease 3600
dhcpd ping_timeout 750
dhcpd auto_config outside
dhcpd enable inside
terminal width 80
Cryptochecksum:XXXXXXXXXXXXXXXXXX
: end
0
 
LVL 20

Assisted Solution

by:calvinetter
calvinetter earned 840 total points
ID: 17853724
You're only half-way there... you haven't removed/re-created the static entries w/ the 'dns' keyword (see my original post).
  eg:
clear xlate
no static (inside,outside) tcp X.X.233.55 www 192.168.1.100 www
static (inside,outside) tcp X.X.233.55 www 192.168.1.100 www dns   <-- must have 'dns' at the end
  <do the same for the other static entries that reference this web server>

You must have the 'dns' keyword at the end of the "nat (inside)..." line *and* any static NAT lines that reference the web server.

cheers
0
 

Author Comment

by:stev0931
ID: 17853825
Just fixed it.  My sh static is now...

static (inside,outside) tcp X.X.233.55 www 192.168.1.100 www dns  netmask 255.255.255.255 0 0
static (inside,outside) tcp X.X.233.55 444 192.168.1.100 444 dns  netmask 255.255.255.255 0 0
static (inside,outside) tcp X.X.233.55 888 192.168.1.100 888 dns  netmask 255.255.255.255 0 0
static (inside,outside) tcp X.X.233.55 13389 192.168.1.100 13389 dns  netmask 255.255.255.255 0 0
static (inside,outside) tcp X.X.233.55 23389 192.168.1.100 23389 dns  netmask 255.255.255.255 0 0
static (inside,outside) tcp X.X.233.55 5500 192.168.1.100 5500 dns  netmask 255.255.255.255 0 0
static (inside,outside) tcp X.X.233.55 https 192.168.1.100 https dns  netmask 255.255.255.255 0 0
static (inside,outside) tcp X.X.233.55 smtp 192.168.1.100 smtp dns  netmask 255.255.255.255 0 0
static (inside,outside) tcp X.X.233.55 3000 192.168.1.203 3000 netmask 255.255.255.255 0 0
static (inside,outside) tcp X.X.233.55 3001 192.168.1.203 3001 netmask 255.255.255.255 0 0

But it still isn't working when I try to go out via HTTP to the web server.  I also tried an nslookup from the machine and it said X.X.233.55, not 192.168.1.100.  Any suggestions?  (Also, I did try clearing xlate and the DNS cache on the machine)
0
 
LVL 20

Assisted Solution

by:calvinetter
calvinetter earned 840 total points
ID: 17854675
Good grief!  6.3(1) is what your PIX is running?!  Save the current config & reboot the PIX.  If you have any internal DNS servers, make sure to clear the DNS cache on them as well as your test workstation.
   If your PIX is has current Cisco SmartNet support, upgrade immediately to 6.3(5)!!  6.3(1) is quite buggy, & has some security problems that're fixed in the latest 6.3(5).
   If you can't upgrade the PIX, & you have internal DNS servers, you might just slap a DNS entry on your internal servers & be done with it.

cheers
0
 

Author Comment

by:stev0931
ID: 17855198
I just tried it and it didn't work...  I feel like we're really close, do you have any other ideas as to what might be wrong?
0
 
LVL 20

Assisted Solution

by:calvinetter
calvinetter earned 840 total points
ID: 17857601
You saved the config & rebooted the PIX?? Are your 'dns' keywords still set for all the web server static lines & the "nat (inside)" line?  
 If at all possible, get off 6.3(1) immediately! It's way too buggy to be used in a production environment.  But if you can't upgrade the PIX to 6.3(5), then your alternative is a DNS entry in your local DNS server(s), as I mentioned before.

cheers
0
 

Author Comment

by:stev0931
ID: 17871459
Thanks!
0

Featured Post

Looking for the Wi-Fi vendor that's right for you?

We know how difficult it can be to evaluate Wi-Fi vendors, so we created this helpful Wi-Fi Buyer's Guide to help you find the Wi-Fi vendor that's right for your business! Download the guide and get started on our checklist today!

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

When speed and performance are vital to revenue, companies must have complete confidence in their cloud environment.
During and after that shift to cloud, one area that still poses a struggle for many organizations is what to do with their department file shares.
Both in life and business – not all partnerships are created equal. As the demand for cloud services increases, so do the number of self-proclaimed cloud partners. Asking the right questions up front in the partnership, will enable both parties …
Both in life and business – not all partnerships are created equal. Spend 30 short minutes with us to learn:   • Key questions to ask when considering a partnership to accelerate your business into the cloud • Pitfalls and mistakes other partners…
Suggested Courses

670 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question