Try something like this.. this is from memory.. i may have some syntax wrong.
name 192.168.50.200 FIOSTV-Inside name x.x.x.x FIOSTV-Outside
static (inside,outside) host FIOSTV-Outside host FIOSTV-Inside netmask
255.255.255.255 0 0access-list outside_access_in permit ip any host FIOSTV-Outside
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 192.168.50.200 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
255.255.255.255 0 0 static (inside,outside) tcp FIOSTV-Outside any FIOSTV-Inside any netmask 255.255.255.255 0 0access-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.
Ace
static (inside,outside) FIOSTV-Outside FIOSTV-Inside netmask 255.255.255.255
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'.
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 192.168.50.200 FIOSTV-Inside)?
Thanks again, Ace
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
192.168.5.0 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 192.168.50.0 subnet.Ace
Added the above two without error. I will find out what Verizon's source is when they install it on Thursday.
Thanks!
Ace
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.
Thanks!
Ace
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 "121.18.13.107".
No, "ip" includes "tcp" and "udp".
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 0.0.0.255 any So for the address you submitted, which Arin states is 121.0.0.0 -
121.255.255.255, I would enter: access-list 101 deny ip 121.0.0.0 0.0.0.255 anyI 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
APNIC has a list of Asian Pacific ranges at:
Ok, thanks. I wasn't sure.
Ace
access-list 101 deny ip 121.0.0.0 0.255.255.255 any
would match the range from 121.0.0.0 - 121.255.255.255
It's a wildcard mask. The "0" signifies the portion that must match exactly. The "255" signifies the "don't care" portion.
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 121.0.0.0 255.0.0.0 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.
In news:c%zKj.34230$Cj7.6397@pd7urf2no, Walter Roberson typed:
Walter,
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.
Would be set as the following:
-------------------------------------------------- access-list 101 deny ip 24.0.0.0 255.0.0.0 any !Most of Cable access-list 101 deny ip 58.0.0.0 255.0.0.0 any !China access-list 101 deny ip 59.0.0.0 255.0.0.0 any !China access-list 101 deny ip 60.0.0.0 255.0.0.0 any !China access-list 101 deny ip 61.0.0.0 255.0.0.0 any !China access-list 101 deny ip 81.0.0.0 255.0.0.0 any !Brussels access-list 101 deny ip 114.0.0.0 255.0.0.0 any !China access-list 101 deny ip 115.0.0.0 255.0.0.0 any !China access-list 101 deny ip 116.0.0.0 255.0.0.0 any !China access-list 101 deny ip 117.0.0.0 255.0.0.0 any !China access-list 101 deny ip 118.0.0.0 255.0.0.0 any !China access-list 101 deny ip 119.0.0.0 255.0.0.0 any !China access-list 101 deny ip 120.0.0.0 255.0.0.0 any !China access-list 101 deny ip 121.0.0.0 255.0.0.0 any !China access-list 101 deny ip 122.0.0.0 255.0.0.0 any !China access-list 101 deny ip 123.0.0.0 255.0.0.0 any !China access-list 101 deny ip 124.0.0.0 255.0.0.0 any !China access-list 101 deny ip 125.0.0.0 255.0.0.0 any !China access-list 101 deny ip 126.0.0.0 255.0.0.0 any !China access-list 101 deny ip 169.0.0.0 255.240.0.0 any !China access-list 101 deny ip 202.0.0.0 255.0.0.0 any !China in AfriNIC access-list 101 deny ip 203.0.0.0 255.0.0.0 any !China access-list 101 deny ip 210.0.0.0 255.0.0.0 any !China access-list 101 deny ip 211.0.0.0 255.0.0.0 any !China access-list 101 deny ip 218.0.0.0 255.0.0.0 any !China access-list 101 deny ip 219.0.0.0 255.0.0.0 any !China access-list 101 deny ip 220.0.0.0 255.0.0.0 any !China access-list 101 deny ip 221.0.0.0 255.0.0.0 any !China access-list 101 deny ip 222.0.0.0 255.0.0.0 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:
Ace
Thanks for pointing that out. Don't you love platform specific quirks?
Best Regards, News Reader
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.
Ace
Walter or anyone,
Sorry for all the questions. I'm obviously still new at this. I was trying to enter some of the access-list blocks I created with using a remark. I tried the following and none of them worked:
! access-list outside_access_in deny ip 24.0.0.0 255.0.0.0 any !Most of Cable - Canada and others access-list outside_access_in deny ip 58.0.0.0 255.0.0.0 any ! China access-list outside_access_in deny ip 58.0.0.0 255.0.0.0 any remark
access-list outside_access_in deny ip 58.0.0.0 255.0.0.0 any remark China
Once I get them all together, will it allow me to copy/paste the whole thing in one shot?
Thank you,
Ace
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.
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
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!
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!
Thanks, Ace
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: tftp:/// [pcap] copy http[s]://[:@][:]/ flash[:[image | pdm]] copy tftp[:[[//location][/pathname]]] flash[:[image | pdm]] pixfirewall# write ? Usage: write erase|floppy|mem|terminal|standby write net []: pixfirewall# configure ? Usage: configure terminal pixfirewall#
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?
Thanks,
Sylvek
First, ensure you have configured.
tftp-server inside IPADDRESS /path/to/config/file
For example,
name 172.16.1.3 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.
Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.