Pix 506e w/5 static outside IPs - How to create a rule to allow ALL tcp/udp traffic from one outside

Discussion in 'Cisco' started by kyoo, Apr 6, 2008.

  1. kyoo

    kyoo Guest

    Try something like this.. this is from memory.. i may have some syntax

    name FIOSTV-Inside
    name x.x.x.x FIOSTV-Outside

    static (inside,outside) host FIOSTV-Outside host FIOSTV-Inside netmask 0 0

    access-list outside_access_in permit ip any host FIOSTV-Outside


    Telecom Discussions a
    no-spam access to your favorite newsgroup -
    comp.dcom.sys.cisco - 44641 messages and counting
    kyoo, Apr 6, 2008
    1. Advertisements

  2. kyoo

    Aceman Guest

    I know this may be a simple task, but I'm having a little trouble figuring
    it out. I am no expert at PIX ACLs, but when I need something, I google it,
    read up on it and adapt what I find to what I need and eventually getting it
    working. I've already configured internal mail and web services to work from
    the outside world. However I'm having a little difficulty wtih this one.

    Scenario and requirements:
    I have a Business FIOS 5 IP static line at home. I wanted to get the
    double-play (TV and phone) on the line. They first said you can't do it with
    a static line, but then I got someone else who said I can, but I need to use
    up one of my IPs. No problem I said, but I added how will I configure that
    through a PIX 506e? They said you can't and need their provided POS
    Actiontec, which I still have in the closet. They said pick one of the IPs
    and send ALL traffic to the Actiontec plugged into your current network.
    Create a private network with the Actiontec and the TV boxes will plug into
    that subnet. Cool, thought this should be a cinch. But having trouble
    setting it up. Not sure how to allow ALL traffic from the one external IP to
    the IP configured on the Actiontec's "external" interface.

    I have a PIX 506e IOS version 6.3(5).

    Names created (using x.x.x.x as one of my external IPs):
    name FIOSTV-Inside
    name x.x.x.x FIOSTV-Outside
    (Funny when I created the names, they didn't show up in the PDM. Did I do
    something wrong?)

    I'm thinking to try:
    static (inside,outside) udp FIOSTV-Outside any FIOSTV-Inside any netmask 0 0
    static (inside,outside) tcp FIOSTV-Outside any FIOSTV-Inside any netmask 0 0

    access-list outside_access_in permit tcp any host FIOSTV-Outside eq any
    access-list outside_access_in permit udp any host FIOSTV-Outside eq any

    Or should I create a group for tcp-udp defining ports 1-65536 and allow it
    by the group name? But I thought this would be over-doing it because a
    simple 'any' would work?

    If I forgot anything concerning or if you need me to elaborate further,
    please advise.

    I will be thankful for any suggestions anyone may provide.

    Aceman, Apr 6, 2008
    1. Advertisements

  3. static (inside,outside) FIOSTV-Outside FIOSTV-Inside netmask

    access-list outside_access_in permit ip any host FIOSTV-Outside

    Except that to reduce risk, I would find out the IPs that will be sending
    the traffic, and only permit those IPs instead of 'any'.
    Walter Roberson, Apr 6, 2008
  4. kyoo

    Aceman Guest

    Thank you, Walter.

    You mean the actual Verizon source IP?

    In your access-list statement, shouldn't I specifically to allow all tcp/udp
    traffic to the Actiontec's outside interface, which I named "FIOSTV-Inside"
    (name FIOSTV-Inside)?

    Thanks again,
    Aceman, Apr 7, 2008
  5. kyoo

    Aceman Guest

    This makes sense. Thanks, I will try it and let you know how it works out.
    The scheduled FIOS TV/Phone install is this Thurs (4/10/08), so we'll see
    how it works. I will test it with a laptop on the "inside" of the Actiontec subnet and see what happens. I know they want to do some changes
    in the Actiontec, which is fine and with this it shouldn't bother my subnet.

    Aceman, Apr 7, 2008
  6. kyoo

    Aceman Guest

    Added the above two without error. I will find out what Verizon's source is
    when they install it on Thursday.


    Aceman, Apr 7, 2008
  7. kyoo

    Aceman Guest

    I tried the above however it didn't like the syntax
    This was no problem. This was also the same statement Walter provided. I
    added Walter's static entry and it took it.


    Aceman, Apr 7, 2008
  8. Yes. With "permit ip any", *anyone* on the 'Net would be allowed
    to send most -anything- to your FIOSTV. And they will, they will.
    For example, google search on the IP address "".

    No, "ip" includes "tcp" and "udp".
    Walter Roberson, Apr 7, 2008
  9. kyoo

    Aceman Guest

    Hmm, those good 'ole Chinese attackers hard at work. I guess they are a
    bunch of Datas that don't sleep. Maybe I should just block every Pacific Rim
    subnet that exists since most attacks eminate from out there anyway. What's
    disturbing trying to pinpoint an IP in China and many other Asian country is
    most of them do not own computers at home but rather frequent cyber cafes
    and do their dirty work from there. Makes it virtually untraceable to
    identify the actual culprit. It's almost like tracking down who made an
    obscene phone call from a busy corner bar in Philly or NY.

    Basically I would use (please correct me if I'm wrong);
    access-list 101 deny ip ADDRESS any
    So for the address you submitted, which Arin states is -, I would enter:
    access-list 101 deny ip any

    I remember finding a link in the past that has ACLs pre-created to block all
    or most of China and Korean subnets, but I can't seem to find it. I thought
    I bookmarked it. I found another link (http://www.unixhub.com/block.html)
    with a list of Chinese and Korean subnets to block, but it seems somewhat
    dated and I would have manually create an ACL for each entry and there's

    APNIC has a list of Asian Pacific ranges at:

    I found this too but it seemse easier to just block the /8's in Apnic's
    Ok, thanks. I wasn't sure.

    Aceman, Apr 8, 2008
  10. kyoo

    News Reader Guest

    access-list 101 deny ip any

    would match the range from -

    It's a wildcard mask.
    The "0" signifies the portion that must match exactly.
    The "255" signifies the "don't care" portion.
    News Reader, Apr 8, 2008
  11. Not in PIX 4/5/6 it isn't. PIX 6 uses "netmask" syntax, not
    IOS wildcard syntax. To deny the entire 121 range on PIX 6 would be

    access-list 101 deny ip any

    As a side note: the particular 121 host IP that I referred to earlier
    is responsible for more attacks on my home system than the next
    three highest networks put together. Not "clever" attacks -- they
    are always the same -- but they are extremely persistant.
    Walter Roberson, Apr 8, 2008
  12. kyoo

    Aceman Guest


    Thanks for the info. :)

    Copied and pasted the list of subnets from the following link. I added a
    couple I thought to block too like cable 24 block and the 81 block from the
    link you provided earlier. I then created the ACL below it to block these
    subnets. I hope I didn't make a mistake.
    http://www.apnic.net/db/ranges.html (Most of cable) (Brussels)* (Reg transferred to AfriNIC)

    Would be set as the following:
    access-list 101 deny ip any !Most of Cable
    access-list 101 deny ip any !China
    access-list 101 deny ip any !China
    access-list 101 deny ip any !China
    access-list 101 deny ip any !China
    access-list 101 deny ip any !Brussels
    access-list 101 deny ip any !China
    access-list 101 deny ip any !China
    access-list 101 deny ip any !China
    access-list 101 deny ip any !China
    access-list 101 deny ip any !China
    access-list 101 deny ip any !China
    access-list 101 deny ip any !China
    access-list 101 deny ip any !China
    access-list 101 deny ip any !China
    access-list 101 deny ip any !China
    access-list 101 deny ip any !China
    access-list 101 deny ip any !China
    access-list 101 deny ip any !China
    access-list 101 deny ip any !China
    access-list 101 deny ip any !China in AfriNIC
    access-list 101 deny ip any !China
    access-list 101 deny ip any !China
    access-list 101 deny ip any !China
    access-list 101 deny ip any !China
    access-list 101 deny ip any !China
    access-list 101 deny ip any !China
    access-list 101 deny ip any !China
    access-list 101 deny ip any !China

    Can I just copy and paste the whole block one shot into a PIX session?

    I'm going to create a cracker/scanners and spam list too from:

    I hope I'm not duplicating something someone else already created. If not, I
    hope this helps others out there. Do you think I should start a new thread
    with this using an appropriate subject?

    Aceman, Apr 8, 2008
  13. kyoo

    News Reader Guest

    Thanks for pointing that out. Don't you love platform specific quirks?
    Best Regards,
    News Reader
    News Reader, Apr 8, 2008
  14. kyoo

    Aceman Guest

    In Aceman <> typed:

    Didn't want to reply to myself, but forgot to ask in my previous post - Will
    adding all these subnets slow down the PIX? I have much more and by the time
    I'm done the size will probably be 5x or more of the list I posted.

    Aceman, Apr 9, 2008
  15. kyoo

    Aceman Guest

    Aceman, Apr 9, 2008
  16. With a PIX 506E running PIX 6.3 (like you are) then you can
    use 'access-list compiled' to compile access-lists so that they
    have near linear time access. It chews up memory to do it.
    But the 506E normally runs quickly enough that -not- compiling
    the ACLs is not a serious problem -- it is rated to 100 megabits
    per second cleartext throughput (if my memory serves me),
    so unless you have it working with a fairly active network,
    it is "fast enough". You don't want to try to have a 506E front
    a gig network, or cover too many VPNs, and if compiling your
    ACLs on the 506E runs you dangerously low on memory (considering
    the connection load you are running) then chances are that you
    should be using a higher-end device anyhow.
    Walter Roberson, Apr 9, 2008
  17. Note that the PIX will throw away comment lines in what it stores
    in memory; when you view the configuration, the comment lines
    will not be there.
    Comments cannot be put on the end of a line in PIX 6.
    An ACL 'remark' must be a line of its own, such as
    access-list outside_access_in remark <China>

    If you use -exactly- the same text for two remarks, then it might
    decide that the line is a duplicate and drop the second one, just
    the way that it drops duplicate permit or deny entries. At least
    that used to happen; I don't know if that behaviour got changed
    in later PIX 6.3.

    The way I handled this sort of thing was that I had a "master"
    copy of the configuration, fully commented, stored on a tftp server,
    and it was always the master configuration that I would edit.
    Then I would tftp the revised configuration over to the PIX,
    rather than doing the configuration changes on the PIX.
    The methods needed to get this all to work nicely involve some
    subtle undocumented configuration behaviours -- nothing too
    difficult, but you have to know the right order to put the
    commands in to the configuration file. What -does- get tricky is
    when the PIX you want to update is on the other end of a VPN
    link, 3000 miles away!
    Walter Roberson, Apr 9, 2008
  18. kyoo

    Aceman Guest

    Thanks for the advise. I created two text files, one for the master config
    with comments and one without.

    If I understand you correctly, you are suggesting I put this all together
    into one config, meaning my current config and these changes, then tftp them
    up to the PIX? I assume then there is no way to copy/paste the whole block
    into a telnet session?

    I can see that would be kind of tricky if you are VPN'd in using the PIX and
    the Cisco client and trying to update a PIX. I myself would rather be onsite
    in case of any issues, but then again, 3000 miles away... you can't simply
    beam over there and back when you're done!

    Aceman, Apr 11, 2008
  19. kyoo

    sylvek Guest

    Hi Walter!

    Do you recall the TFTP upload command that you used on PIX 6.*.*?

    I'm really curious, I'm only familiar with "conf(igure) t(erminal)"
    and "conf(igure) h(ttps)". As far as I know "copy" doesn't handle
    the configuration either:

    pixfirewall# copy ?
    Usage: copy capture:<capture-name> tftp://<location>/<pathname> [pcap]
    copy http://[<user>:<password>@]<location>[:<port>]/<pathname>
    flash[:[image | pdm]]
    copy tftp[:[[//location][/pathname]]] flash[:[image | pdm]]
    pixfirewall# write ?
    Usage: write erase|floppy|mem|terminal|standby
    write net [<tftp_ip>]:<filename>
    pixfirewall# configure ?
    Usage: configure terminal

    Knowing the TFTP way would be helpfull, as we are stuck with
    at least one PIX506E that by default became a focal point of our VPNs.

    Could you sketch an example from what you remember?


    sylvek, Apr 11, 2008
  20. First, ensure you have configured.

    tftp-server inside IPADDRESS /path/to/config/file

    For example,

    name zippy
    tftp-server inside zippy /usr/pix/pox-current

    You can get away without this configuration statement only if your
    tftp-server is off of the ethernet1 interface. Note I don't say
    "off of the inside interface"; for example, if you had a 525 or
    535 without the 2-port fastethernet card (just gig cards),
    ethernet1 would not refer to any physical interface but it would still
    be ethernet1 that the PIX attempted to use. Play it safe and
    put in the tftp-server command. In the tftp-server command, you do
    not need to give accurate info about the server IP or file path
    (you can override those later if you want), but the tftp-server command
    is the only way to specify which interface will be used to contact
    the tftp server.

    Once you have the tftp-server command configured, ensure you
    are in terminal configuration mode (config terminal), and *in config mode*
    give the command

    configure net

    This form of the command will use the interface, IP address, and file path
    from the tftp-server command and will attempt to load the file.

    This 'configure net' (or 'config net') command can ONLY be used
    when you are already in terminal configuration mode. Outside of
    terminal configuration mode, 'configure net' will give you an error
    about 'net' not being a valid option.

    You can add the information about where to get the file from to
    the config net command line, such as

    config net zippy:/usr/pix/pox-previous

    Notice the ':' between the parts, rather than the space that was
    used on the tftp-server command.

    When you config net, the file is tftp'd in, 512 bytes at a time,
    and after each 512 byte block is read, all of the lines that end
    before the end of the 512 byte block will be processed as if you
    had entered them at "configure terminal" level. When the last of
    the complete lines is processed, any partial line will be saved for
    the next time, and the next 512 byte block will be read, any
    pending partial line processed, the rest of the complete lines processed,
    and so on. Read a block, process as much of it as possible, *then*
    go back for another block. This is a different arrangement than
    for IOS: when you "copy tftp running-config" in IOS, the -complete-
    file is copied before -any- of it is processed, but in PIX 6 the
    file is processed as you go. If the configuration file you are processing
    happens to do something like change the IP address of the interface
    you are reading from, the rest of the commands in that 512 byte block
    will be processed, but the rest of the tftp would then fail. If
    your tftp server happens to be on the other side of a VPN and you
    disrupt the VPN (e.g., to change the crypto map access-list), then
    if you don't get the VPN back up (and SAs negotiated!) by the end of
    the 512 byte block, then the tftp will fail. (Danger, Will Robinson!)

    Now, because each command is processed as if you were in
    "configure terminal" mode, you face the same situation as in that mode:
    what is read in *adds* to the existing configuration, rather than
    *replacing* the current configuration.

    There are some PIX commands that automatically replace the previous
    configuration (e.g., 'logging buffer 4' would change the buffer
    logging level to 4 no matter what the previous 'logging buffer'
    level was). But there are also a number of PIX configuration statements
    in which you need to 'clear' or 'no' the previous configuration line(s)
    before you can put in changed lines. And sometimes you have to be subtle
    about the order you clear things in: for example, you have to
    clear the access-lists before you can clear the object-groups
    if your access-lists refer to the object groups.

    Do NOT start your master configuration file with "clear config"
    or anything like that, because that will clear the tftp-server setting
    you have, and clear the IP address on the interface you are tftp'ing
    through. If those settings did not get re-established exactly the way
    they were before the end of that same 512 byte block, you would be lost.
    Instead, clear in bits and pieces, only clearing something just before
    you establish new values for it.

    The following is the order I ended up clearing elements in:

    clear nameif
    clear fixup
    no fixup protocol smtp 25 (if you want to use ESMTP!)
    clear names
    clear access-list
    clear object-group
    clear logging
    clear logging disabled
    no logging standby
    no logging console
    no logging message 400018 (and related)
    clear icmp
    no ip audit name ids_outside_attack (adjust name to suit)
    no ip audit name ids_outside_info (adjust name to suit)
    clear vpngroup
    clear ip local pool
    clear pdm
    clear global
    clear nat
    clear static
    clear access-group
    clear rip
    clear aaa-server
    clear ntp
    clear http
    clear snmp-server
    no snmp-server enable traps
    clear sysopt
    no sysopt connection permit-ipsec
    clear cypto sa
    clear crypto map
    clear isakmp
    clear telnet
    clear ssh
    clear dhcpd
    clear username

    A different and much more complex order must be used for updating
    configurations that live on the other sides of VPNs.
    Walter Roberson, Apr 11, 2008
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.