Re: Open port PIX 501
- From: roberson@xxxxxxxxxxxxxxxxxx (Walter Roberson)
- Date: Thu, 28 Jul 2005 17:00:17 +0000 (UTC)
In article <1122548484.917015.132010@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>,
ELR <elr1981@xxxxxxxxx> wrote:
:i can't open the port in my PIX.
:I need open the port 1000 to point to the IP 10.254.254.222.
:PIX Version 6.1(4)
It would be better to upgrade to 6.1(5) [if you must stick with 6.1]
or 6.2(4) [current General Deployment release] or 6.3(4)110
[newest release.] There are quite a few bug fixes in 6.1(5).
http://www.cisco.com/univercd/cc/td/doc/product/iaabu/pix/pix_sw/v_61/relnotes/pixrn615.htm
:access-group outside_access_in in interface outside
:access-group inside_access_in in interface inside
:access-list inside_access_in permit tcp any gt 1023 any eq 443
:access-list inside_access_in permit tcp any any eq domain
:access-list inside_access_in permit udp any any eq domain
You have been slightly inconsistant there. If you are going to bother
to control by outgoing port number for the https and http cases,
then you should also control by outgoing port number for the DNS
case. If you check your traffic, you will find that there are
only a small handful of cases (clients: source port udp 137, udp 53,
dynamic udp > 1023; servers fixed source port usually > 1023).
Not restricting the source port won't cause any trouble: it just
isn't quite consistant with the tight restriction philosophy you
have in the other rules.
Also, in practice only DNS servers doing zone transfers need tcp.
Although in theory -any- DNS transaction could go TCP instead
of UDP, it would be a highly unusual client which did not stick
to UDP.
:access-list inside_access_in permit tcp any gt 1023 any eq ftp-data
:access-list inside_access_in permit tcp any gt 1023 any eq ftp
:access-list inside_access_in permit udp any gt 1023 any eq 20
:access-list inside_access_in permit udp any gt 1023 any eq 21
In practice, FTP never uses UDP.
:access-list inside_access_in permit tcp any any eq smtp
The source port for outgoing smtp connections is dynamic > 1023.
:access-list outside_access_in permit tcp any eq 443 any gt 1023
These and similar TCP ACL entries are unnecessary and could lead
to security problems. When an outgoing connection is formed, the PIX
Adaptive Security Algorithm automatically inserts a temporary ACL
entry to permit reply packets, so you should not have explicit
entries for replies (at least not for TCP.)
:access-list outside_access_in permit tcp any eq telnet any gt 1023
You will need to add an entry,
access-list outside_access_in permit tcp any host XX.XX.XX.YY eq 1000
OR
access-list outside_access_in permit udp any host XX.XX.XX.YY eq 1000
(you didn't specify whether you needed tcp 1000 or udp 1000 opened.)
In that statement, XX.XX.XX.YY is one of your public IPs. It has been
awhile since 6.1(4) and I no longer recall exactly what special
treatment 6.1(4) needed if the PIX outside interface IP itself is
the destination: if that's what you want, then you might need to use
access-list outside_access_in permit tcp any any eq 1000
(or the UDP equivilent.)
The details about using the PIX outside interface IP as the
destination change in 6.2 and change again in 6.3.
:ip address outside XX.XX.XX.XX 255.255.255.0
:ip address inside 10.254.254.1 255.255.255.0
:global (outside) 1 interface
:global (outside) 1 192.168.200.1
That second 'global' is almost certainly wrong. The only time it
could possibly take effect is if you manage to "fill up" the interface
IP translation -- and if you manage to do that, you don't want the
spill-over packets going out onto the net with an RFC1918 private
interface IP. You should probably delete that second 'global' statement.
:nat (inside) 1 0.0.0.0 0.0.0.0 0 0
:What I need??????????
static (inside,outside) XX.XX.XX.YY 10.254.254.222 netmask 255.255.255.255
OR
static (inside,outside) tcp XX.XX.XX.YY 1000 10.254.254.222 1000 netmask 255.255.255.255
(or the udp equivilent)
OR
static (inside,outside) tcp interface 1000 10.254.254.222 1000 netmask 255.255.255.255
(or the udp equivilent)
--
Oh, to be a Blobel!
.
- References:
- Open port PIX 501
- From: ELR
- Re: Open port PIX 501
- From: Walter Roberson
- Re: Open port PIX 501
- From: ELR
- Open port PIX 501
- Prev by Date: Re: Fires and SmartNet contracts
- Next by Date: Re: vpn/ split tunnel question
- Previous by thread: Re: Open port PIX 501
- Next by thread: Re: clear line vty on Cisco 7200
- Index(es):
Relevant Pages
|