Haven't used a Cisco in years...

In article , MeTed wrote: :I'm trying to re-introduce myself to a Cisco 1710 (Pix 6.3).

I'm confused. The 1700 series runs IOS, not PIX software.

:Everything is :already configured from a previous admin. Here are my questions:

:I need to open up a port and forward it to a private IP (192.168.1.25) on my :LAN. Is the below the right config?

:access-list inbound permit tcp any host [PUBLIC_IP] eq 3000

That looks like PIX, not IOS. For IOS you would have needed the word 'extended' in order to use a named access-list .

:access-list outbound permit tcp any any eq 3000

It isn't clear why you would want that line, unless you are trying to connect to -other- system's tcp 3000 instead of trying to configure inward access on tcp 3000 to your own systems.

You will need to add

access-group inbound in interface outside

If you are being restrictive about what you allow out, then you will also need

access-group outbound in interface inside

but if you do that then you start running into issues about (e.g.) needing to also explicitly configure outbound DNS queries, outbound http and https and smtp and ...

:static (inside,outside) tcp [PUBLIC_IP] 192.168.1.25 3000 netmask

255.255.255.255 0 0

You need to add a 3000 between [PUBLIC_IP] and the internal IP.

:Next question, and this is what I can't remember, can I simply add these :entries into the Cisco, or, when I want to make a change do I have to :re-enter the entire config?

New access-list entries normally go at the end of the list, so if you have 'deny' further up in the list, you could run into trouble unless you take special steps to put the entry before the appropriate 'deny'.

In PIX 6.2 and before, the only way to add an entry in the middle of an access-list is to remove the list and rebuild it with the new entry in it's proper place. You would not need to change the

-whole- configuration of the PIX, just the access-list (and after you remove an access-list and put it back, you need to redo any access-group or nat or static or crypto map command that referred to it.)

In PIX 6.3, a method was added to do insertions in place. You "show" the access-list and you will see line numbers. For example, it might display

access-list inbound line 17 permit tcp any host [PUBLIC_IP] eq smtp access-list inbound line 18 permit udp any host [PUBLIC_IP] eq dns

In order to add a new entry in place, put it in with the infix line number that it is to be inserted *before*. For example to put the new entry between lines 17 and 18, you would use

access-list inbound line 18 permit tcp any host [PUBLIC_IP] eq 3000

The existing line 18 would get pushed down to line 19.

The order of 'static' commands only matters in obscure circumstances involving "policy static": other than that, the order does not matter because you are not permitted to form overlapping static's in most cases (and when you are, it is longest-match.) You *do*, though, need to be aware that different kind of static and nat commands have different priorities -- static mentioning a port number is lower priority that a static that applies to the entire IP. [Personally I think it would have been better the other way around, so that you could easily redirect a particular port to one place and have all other ports go to a different place.]

:Last question: How do I backup the configuration so I have a legitimate way :to restore in the event of disaster?

Go into configuration mode ( config terminal ), use the tftp-server configuration command if you haven't done so, and then "write net". NB "write net" will only when you are in configuration mode! WHich makes it easy to overlook the command or to think it has disappeared.

Thanks for all the info. You're right, I don't need to open outbound traffic on 3000. So, just to rehash, this is what I need to do:

access-list inbound [LINE#] permit tcp any host [PUBLIC_IP] eq 3000

static (inside,outside) tcp [PUBLIC_IP] 3000 192.168.1.25 3000 netmask

255.255.255.255 0 0

-OR- Were you saying there is another way to forward the public ip/port to a private ip/port?

In article , MeTed wrote: :So, just to rehash, this is what I need to do:

:access-list inbound [LINE#] permit tcp any host [PUBLIC_IP] eq 3000

:static (inside,outside) tcp [PUBLIC_IP] 3000 192.168.1.25 3000 netmask

255.255.255.255 0 0

Right.

:-OR- :Were you saying there is another way to forward the public ip/port to a :private ip/port?

If [PUBLIC_IP] is *not* the IP of your outside interface, then

static (inside,outside) [PUBLIC_IP] 192.168.1.25 netmask 255.255.255.255

would allow all ports to be forwarded, with the actual actively forwarded ports being restricted by the access-group applied to the outside interface (i.e., the 'inbound' ACL.)

What I was indicating was that you cannot mix these two forms.

There is a related third form, a static command with an access-list that has a different priority yet...

Thanks again...now, one last issue. I know we spoke about adding to the access list without having to re-enter all previous entries. Does the same hold true for the static entry I need to make?

Looking at the 'configure memory' command, it's my understanding that I can do this:

:config t :access-list inbound [LINE#] permit tcp any host [PUBLIC_IP] eq 3000 :static (inside,outside) tcp [PUBLIC_IP] 3000 192.168.1.25 3000 netmask

255.255.255.255 0 0 :configure memory

Will that effectively merge those changes into NVRAM?

Thanks again for all the help...

In article , MeTed wrote: :now, one last issue. I know we spoke about adding to the :access list without having to re-enter all previous entries. Does the same :hold true for the static entry I need to make?

New static entries are added to the end of the group of the same kind of static entries, and you can use "no" to remove any one existing static entry you want.

The order of static entries almost never matters: it is important

*only* for "policy static", as all other kinds of static and nat do not permit you to have overlapping entries, or else use "longest match" to resolve overlaps. "policy static" is the only case in which overlaps are possible and -not- resolved by "longest match".

In article , MeTed wrote: |Looking at the 'configure memory' command, it's my understanding that I can |do this:

|:config t |:access-list inbound [LINE#] permit tcp any host [PUBLIC_IP] eq 3000 |:static (inside,outside) tcp [PUBLIC_IP] 3000 192.168.1.25 3000 netmask

255.255.255.255 0 0 |:configure memory

|Will that effectively merge those changes into NVRAM?

Not quite, no.

When you use "configure terminal" (aka "config t") then anything you enter is immediately put into effect, as soon as the line is parsed and analyzed -- the "running config" is immediately changed, but not the saved "startup config".

When you use "configure memory", the PIX re-reads the startup config and re-parses it, as if you had typed in each of the lines one by one into "configure terminal". For example if you were to clear the current configuration, set up a few things, and then "configure memory" then the saved settings would be merged into the running configuration. I have never had a need for this facility.

You can save the current running configuration into NVRAM as the startup configuration by using the command "write memory".

You can also use "configure net" or [on older devices] "configure floppy" to merge in configurations from a tftp server or floppy disk into the running configuration.

PIX through 6.x only offers these configuration methods. PIX 7.0 offers a real filesystem and a ability to copy configurations into the filesystem without affecting the running configuration.

Okay...so, ''write memory' would "add" these changes to the running config and the startup config?

In article , MeTed wrote: :Okay...so, ''write memory' would "add" these changes to the running config :and the startup config?

No, changes are added -immediately- to the running config. "write memory" does not "add" changes to the startup config, it rewrites the startup configuration with whatever is currently in the running configuration. ("add" to the startup configuration would imply that any non-conflicting setting in the startup configuration would be preserved, which is not the case: the startup config is overwritten entirely.)

Sorry for my confusion, but I think what you're saying is that I do not perform a 'write memory' command in order for the changes to propagate?

In article , MeTed wrote: :Sorry for my confusion, but I think what you're saying is that I do not :perform a 'write memory' command in order for the changes to propagate?

Depends what you mean by 'propagate' ;-)

As I emphasized earlier, every command you enter in via "config t" takes effect *immediately* .

Changes to the running configuration are not, though, written into the startup configuration until you "write memory".

"config memory" has a confusingly similar name, but involves re-parsing the startup configuration and merging whatever it says with the running configuration. "config memory" does not change the startup configuration. Only "write memory" changes the startup configuration in PIX through PIX 6.x.

Gotcha....

So, the two commands:

:access-list inbound [LINE#] permit tcp any host [PUBLIC_IP] eq 3000 :static (inside,outside) tcp [PUBLIC_IP] 3000 192.168.1.25 3000 netmask

255.255.255.255 0 0

will indeed take effect immediately into the running config, but not the startup config. 'Write memory' would copy the running config (incuding the two additions I make) into a new startup config.

Yes?

In article , MeTed wrote: |Gotcha....

|So, the two commands:

|:access-list inbound [LINE#] permit tcp any host [PUBLIC_IP] eq 3000 |:static (inside,outside) tcp [PUBLIC_IP] 3000 192.168.1.25 3000 netmask

255.255.255.255 0 0

|will indeed take effect immediately into the running config, but not the |startup config. 'Write memory' would copy the running config (incuding the |two additions I make) into a new startup config.

Right. Provided, that is, that the access-list named 'inbound' is the access-list that has been applied to the outside interface previously by the command access-group inbound in interface outside If you modify the wrong access-list, you won't be able to make the connection ;-)