Open port PIX 501

hi,

that it regulates I need I to create in my PIX 501 to point port 25 of the IP publishes of my pix, to my server of mail?

regards

static (inside,outside) tcp interface smtp SERVERINTERNALIP smtp netmask

255.255.255.0

access-list out2in permit tcp any interface outside eq smtp access-group out2in in interface outside

In article , ELR 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).

: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)

Thank you.

it already works well