|
jwh posted:Actually, I see what you mean- it looks like the held column for BGP in 'show proc mem' is roughly twice what is reported in 'show ip bgp su'. I don't know enough about IOS internals to know why that is. Folks, if you really need to calculate it you need to know data structure. held and summary is always different If you want to reverse engineer is install one bgp prefix and check your memory for a some period of time like 5 time in row for a 15 min then install second bgp prefix do same steps again.
|
#
?
Jul 16, 2009 21:16
|
|
|
|
| # ? May 30, 2024 07:05 |
|
|
jwh posted:If anyone is doing 802.1x on their wired LAN, I'd be interested in hearing about it. You can use just a basic MD5 authentication if you don't need certificate and you wish to use single sing-on. An example integrated ACS/Radius with Active directory and use MD5 as authentication mechanism. btw In fact EAP-FAST the best one from all EAP's and now it everywhere wirless/wimax/lte and most probably it will replace sim cards : )))
|
|
#
?
Jul 16, 2009 21:23
|
|
|
Hey folks. I've had a m0n0wall for a long time and now I'm I have a novice understanding of basic networking and IOS commands and I believe I have most of this running correctly. However, I cannot access the Internet over my WAN connection and I'm down to it being a NAT problem or a routing problem, I think. I have configured vlan1 to handle the four physical Ethernet LAN ports, FastEthernet0 through 3. FE4 is the WAN connection and is configured to obtain its IP address via DHCP. These things are working; LAN hosts can obtain an IP address and ping the LAN gateway, and FE4 obtains an IP address from my cable connection. Further, when I enable ip domain lookup, I can ping google.com or yahoo.com just fine from the CLI, so I know the router itself has access to the Internet. Here's my config and route table: code:Further, I realize that I don't have a DNS server listed for DHCP clients in the config. I had a valid server in there when trying this earlier (208.67.222.222) and was not successful in accessing the Internet. Finally, I'm a bit confused on the route table. I'm trying to discern if I have a conflict. My DHCP pool for the LAN has a gateway of 10.0.0.254 and a subnet of /24, but my ISP has a 10.37.0.1/32 network running around, and I'm wondering if having both of those networks there and trying to dump everything out to the public IP address gateway the ISP handed down is flummoxing things. Maybe I'm reading too much into it. Anyway, any help would be exceedingly, well, helpful. 
|
|
#
?
Jul 18, 2009 03:09
|
|
|
Mackieman posted:Now, I realize I don't have a NAT statement in the config. I suppose the reason for that is that I'm not sure where to put it. Should I put ip nat inside on FE4 or ip nat outside on vlan1? I'm doing this from memory, as I don't have any of my boxes powered at the moment. put "ip nat inside" on vlan1, and "ip nat outside" on fe4 Then, build an access-list, say: access-list 100 permit ip 10.0.0.0 255.255.255.0 any Then, apply an ip nat statement: ip nat inside source list 100 overload fe4 Mackieman posted:Further, I realize that I don't have a DNS server listed for DHCP clients in the config. I had a valid server in there when trying this earlier (208.67.222.222) and was not successful in accessing the Internet. Mackieman posted:Finally, I'm a bit confused on the route table. I'm trying to discern if I have a conflict. My DHCP pool for the LAN has a gateway of 10.0.0.254 and a subnet of /24, but my ISP has a 10.37.0.1/32 network running around, and I'm wondering if having both of those networks there and trying to dump everything out to the public IP address gateway the ISP handed down is flummoxing things. Maybe I'm reading too much into it.
|
|
#
?
Jul 18, 2009 04:56
|
|
|
jwh posted:helpful information Excellent, thanks. I'll fire that up in the morning and we'll see what happens.
|
|
#
?
Jul 18, 2009 05:25
|
|
|
Jwh was very close with the ip nat statement. Everything else was absolutely correct. ip nat inside source list 100 interface FastEthernet4 overload Looks like you have an 871w. I am assuming you want the wireless to be on the same lan as the 4 inside ports and all (10.0.0.1-253). To get that going you will need to bridge the wireless and vlan 1 interfaces. global config commands: bridge irb bridge 1 route ip interface config commands: interface Dot11Radio0 no ip address bridge-group 1 interface vlan1 no ip address bridge-group 1 When you get the 2 interfaces bridged you should see a new BVI1 interface pop up (if not just make one by entering the below). Thats the Bridge-Group Virtual Interface that will be your 'inside' 10.0.0.254 address. interface BVI1 ip address 10.0.0.254 255.255.255.0 ip nat inside ip virtual-reassembly I had shipped out an 871w without setting up the wireless, only to find out I had to bridge the backside out once it came up in Boca FL on dmvpn. Luckily the Tunnel and Outside interface didn't have to get mucked with so it wasn't a show stopper. Ahh, mediocre remote victories. Hope this gets you up and running.
|
|
#
?
Jul 18, 2009 08:07
|
|
|
Here is the relevant wireless config for my 851w. interface Dot11Radio0 no ip address ! encryption mode ciphers tkip ! encryption vlan 1 mode ciphers tkip ! ssid fbi.gov vlan 1 authentication open authentication key-management wpa guest-mode wpa-psk ascii 0 whatisinaname ! speed basic-1.0 basic-2.0 basic-5.5 6.0 9.0 basic-11.0 12.0 18.0 24.0 36.0 48.0 54.0 station-role root ! interface Dot11Radio0.1 encapsulation dot1Q 1 native no snmp trap link-status bridge-group 1 bridge-group 1 subscriber-loop-control bridge-group 1 spanning-disabled bridge-group 1 block-unknown-source no bridge-group 1 source-learning no bridge-group 1 unicast-flooding ! interface Vlan1 no ip address ip nat inside ip virtual-reassembly no ip route-cache cef no ip route-cache bridge-group 1 ! interface BVI1 ip address 10.10.10.1 255.255.255.0 ip nat inside ip virtual-reassembly Obviously I'm using a 10.10.10.0 private network, you'll need to change that to match your own, but this should get you started. Also I think the 871 supports wpa2 and multiple vlans, so you have a little bit more flexibility.
|
|
#
?
Jul 18, 2009 09:45
|
|
|
Interesting. I have a Cisco Aironet 1200 AP up and running on my m0n0wall setup (with Cisco 2924 switch) so I hadn't broached the use of WiFi on the 871w, but after I get the core network actually communicating (thanks to the NAT clarifications) I'll see about the WiFi stuff. I had most of the AP configured but the security stuff was throwing me for a loop mostly because I am unfamiliar with the IOS commands for running WPA-PSK. So thanks to each of you for that input.
|
|
#
?
Jul 18, 2009 14:40
|
|
|
Ok, well, not so much. I added the NAT statements as prescribed and still no go. I still get DHCP leases correctly and I get a valid IP address from my ISP that I can ping from the command line so that part is still all good. But no LAN host can access the Internet. Here is the updated config with NAT statements: code:Secondly, when I created access-list 100, the IP subnet I specified to be permitted was 10.0.0.0 255.255.255.0. Every time I enter the command, it is accepted, but when I view the configuration it has been changed to 0.0.0.0 255.255.255.0. Perhaps it does that because it is the base network, but I'm not sure. Thirdly, do I have the inside and outside NAT statements reversed? Should outside be on vlan1 and inside on FE4? I always get confused with regard to how Cisco nomenclature is assigned to traffic flow. Thanks. 
|
|
#
?
Jul 18, 2009 15:24
|
|
|
Your access-list 100 is wrong. Change it from: access-list 100 permit ip 0.0.0.0 255.255.255.0 any to access-list 100 permit ip 10.0.0.0 255.255.255.0 any edit: woops, I hadn't read your second paragraph.
|
|
#
?
Jul 18, 2009 16:24
|
|
|
Yeah, I figured that was part of the issue. Any ideas on how to resolve that little gem?
|
|
#
?
Jul 18, 2009 16:56
|
|
|
Mackieman posted:Yeah, I figured that was part of the issue. Any ideas on how to resolve that little gem? code:
|
|
#
?
Jul 18, 2009 17:24
|
|
|
Mackieman posted:
OK for one, you just need the single 'ip nat inside source list <mylist> interface fas4 overload' statement. Once this is up do a 'show ip nat translation' and you will see it working. Second, Falz already got you on. Third, you have it correct. The inside is your private, think of a fort. Outside is public. Good luck, maybe your next post is through your 871. P.S. Powercrazy posted a WPA1-PSK setup for you. ------- On an unrelated note, had some fun with a sup720 not wanting to boot off its disk1 this morning. Invalid magic number, after new SP and RP rommon's still no dice. Then I reformatted... hadn't since the rommon upgrades, and bing! As long as I can work from home now.
|
|
#
?
Jul 18, 2009 18:02
|
|
|
There are ways to debug problems other then staring at the config. Use some show and debug commands for better insight into the nat problem.
|
|
#
?
Jul 18, 2009 18:13
|
|
|
falz posted:The subnet must be in wildcard format, for a /24, it must be 0.0.0.255: Yep, that makes sense. I had forgotten about the wildcard notation, thanks. Herv posted:OK for one, you just need the single 'ip nat inside source list <mylist> interface fas4 overload' statement. Once this is up do a 'show ip nat translation' and you will see it working. Not so much, no. show ip nat translation shows returns nothing. It's almost as if NAT isn't running or something, even though it is. Also, with the updated access list, though I still get an IP address via DHCP on the LAN, I now can't ping the 871's LAN gateway IP address. Seems like things are sliding from bad to worse. Updated config is available if it is helpful. inignot posted:There are ways to debug problems other then staring at the config. Use some show and debug commands for better insight into the nat problem. Agreed, and I have debug turned on for NAT. Problem is, there are no messages concerning NAT at all. My understanding is that NAT is available in my IOS version and I would be surprised if it wasn't. Is there some global parameter that has to be enabled before this works?
|
|
#
?
Jul 18, 2009 19:55
|
|
|
Your log settings might be such that you don't see any debug messages; or the config is wrong and nothing is hitting nat to be debugged.code:
|
|
#
?
Jul 18, 2009 22:00
|
|
|
Are you getting any debugging messages? If not you need to do "term mon" which will show debug outputs whenever you are telnetted in. If you are a consoled in then you don't need to worry about it.
|
|
#
?
Jul 18, 2009 22:03
|
|
|
When in doubt, wr erase, reload and start over. I just had to literally do a 'no ip nat inside source static <local> <global>' and then paste 'ip nat inside source static <local> <global>' for my static translations to work. You aren't the only one having nat issues today. My xlates are working though! /snarky
|
|
#
?
Jul 18, 2009 22:30
|
|
|
Well, son of a bitch. I guess it's magic, heh. I walked in after leaving it alone for a couple of hours and it was magically working. I'm online through the 871w now. Now I need to educate myself on creating proper ACLs so I'm not an open proxy, among other things. Any tutorials for that sort of thing?
|
|
#
?
Jul 19, 2009 00:56
|
|
|
Google, mate. http://www.cisco.com/en/US/products/sw/secursw/ps1018/products_tech_note09186a00800a5b9a.shtml Understand ACLs backwards, if you're going to be a Cisco guy then you'll be playing with these all the time. Particularly as a newbie, you'll be asked to play with ACLs a lot. See a couple of pages previous where I show how to use ACLs to modify debug output to get IOS to tell you what you want. edit: Page 58 to be exact.
|
|
#
?
Jul 20, 2009 05:59
|
|
|
Tony Montana posted:Google, mate. Right, I've been reading that. I always consult the documentation before asking for help. Problem is, Cisco's documentation can be somewhat cryptic for the seemingly uninitiated such as myself. My query was more directed toward any sources of information that have broken down the process and especially the syntax a little more. I understand the basics of ACLs and how they work, but I haven't the foggiest on how to write a rule correctly to do what I want to do. And I've tried several iterations with little to no success, but I'll keep at it.
|
|
#
?
Jul 20, 2009 15:00
|
|
|
Try this for a starting point Mackie.code:Cheers (e: typo) Herv fucked around with this message at 16:29 on Jul 20, 2009 |
|
#
?
Jul 20, 2009 15:57
|
|
|
Herv posted:Try this for a starting point Mackie. Thanks Herv. I think I've already accomplished that via these lists: access-list 1 permit 10.0.0.0 0.0.0.255 access-list 100 permit ip 10.0.0.0 0.0.0.255 any access-list 199 deny ip any any List 1 was for the BVI stuff to get WiFi working (which totally borked DHCP when I tried to implement it, but I'll work on that another day). Based on what I read, my understanding is that list 100 allows my LAN to access the Internet (and any open sessions can pass traffic back to me of course) and then list 199 blocks any unsolicited inbound traffic, including ICMP. I am ok with this basic setup for now as everything is working and I have not been hax0red.  It is further my understanding that lists are applied in numeric order, meaning inbound traffic is sifted through those lists until it finds one that it applies to. So I could add a list 101 that allowed inbound traffic on ports 9500-9501 and it would apply before list 199 kicked in, even though I would enter rule 101 after rune 199. Only issue is, I haven't been able to locate clear directions on how to specifically open inbound tcp ports for 9500-9501 to a specific LAN host in an ACL. I tried this without success:access-list tcp permit any 10.0.0.250 eq 9500-9501 I didn't think it would work because the syntax looked off. I've read through the Configuring ACLs guide from Cisco and I have yet to locate anything dealing with non-standard ports. eq www would work if I wanted to open pot 80, but not so much for other things.
|
|
#
?
Jul 20, 2009 17:48
|
|
|
OK, you want to make a single access-list (e.g. ip access-list extended <MyOutsideList>) and then apply it to an interface (or logic statement, like your 'IP nat inside source list'). Access list entries are processed from top to bottom, within the single access list. The router won't call another access list on inbound public traffic other than the one bound to its outside interface, for this example. If you see the example in the one I gave you, the access-list is applied to your outside interface, on inbound traffic. Ok so now you want to pass some traffic inside. That's going to require some more static nat statements: ip nat inside source static tcp 10.0.0.250 80 interface FastEthernet4 80 ip nat inside source static tcp 10.0.0.250 9500 interface FastEthernet4 9500 ip nat inside source static tcp 10.0.0.250 9501 interface FastEthernet4 9501 If you are running an access-list on your outside interface (like the one I posted) then add the following lines: code:You can get by without an outside access list, just relying on NAT to govern what gets back inside the router, but I use access lists for good habits. e: typo like a champ Herv fucked around with this message at 19:31 on Jul 20, 2009 |
|
#
?
Jul 20, 2009 19:01
|
|
|
That access list is sorely in need of some udp/53 for DNS to work.
|
|
#
?
Jul 20, 2009 22:42
|
|
|
Herv posted:excellent help for which Mackie is appreciative Thanks Herv. I think I see where that is going, in that I need to create a list that applies to an interface, and then be able to specific individual rules under that which apply to that interface. It's a multi-level sort of thing. falz posted:That access list is sorely in need of some udp/53 for DNS to work. Only if I was running a DNS server inside my LAN, which I am not. DNS is handled via DHCP on the router for me.
|
|
#
?
Jul 20, 2009 23:06
|
|
|
Mackieman posted:Only if I was running a DNS server inside my LAN, which I am not. DNS is handled via DHCP on the router for me. If DNS is working with that _exact_ access list something isn't right (unless your DNS resolver is falling back to TCP). By default DNS tries to look up the name using udp/53 to a recursive resolver, so while your ACL lets outgoing TCP session return traffic back through it, nothing in that list will let returning DNS traffic (on udp/53) back through it.
|
|
#
?
Jul 20, 2009 23:14
|
|
|
Mackieman posted:Only if I was running a DNS server inside my LAN, which I am not. DNS is handled via DHCP on the router for me. Nope they are correct, you are going to have to pass UDP traffic for DNS and anything else like skype. No static nat statements, this is just to get into the public interface where you are getting nat'd at.
|
|
#
?
Jul 21, 2009 00:20
|
|
|
I've never let any udp port through my inbound ACLs and it works fine. This is also the first I've ever heard of DNS working on UDP 53. It does say it in the Wiki entry, but I can assure you I've configured hundreds of networks and never had a port forward or firewall entry for UDP 53; DNS has always made it through. Anyone know why that is?
|
|
#
?
Jul 21, 2009 01:08
|
|
|
Tony Montana posted:I've never let any udp port through my inbound ACLs and it works fine. NAT in most firewall/NAT devices is 'smart enough' to add create translations for UDP traffic passing through the device. The return traffic is permitted through for all protocols so long as it matches an existing translation/connection (by having implicit tcp established/udp established rules). The only thing you need a port forward for on these devices is for outside devices to be able to initiate a connection into your network.
|
|
#
?
Jul 21, 2009 02:12
|
|
|
ragzilla posted:NAT in most firewall/NAT devices is 'smart enough' to add create translations for UDP traffic passing through the device. The return traffic is permitted through for all protocols so long as it matches an existing translation/connection (by having implicit tcp established/udp established rules). The only thing you need a port forward for on these devices is for outside devices to be able to initiate a connection into your network. Yeah, I figured as much. I'm talking about Cisco kit though, like 800 series routers. From what I understood of ACLs, if it isn't in that list then the 'deny ip any any' at the bottom of the ACL won't let it through. This doesn't apply to requests that originate from inside the network, so if a server requests something on UDP 53 the Cisco router will let traffic back in on UDP 53 even if it's not explicitly defined in the ACL? There is no 'tcp/udp established' rules in the ACL and it still works..
|
|
#
?
Jul 21, 2009 02:25
|
|
|
Well if it helps, this is what happens on my home router (3660 from work junk room) when there is no UDP traffic allowed in this ACL:code:*July 20 18:23:04.578: %SEC-6-IPACCESSLOGP: list IN-FASTETHERNET0 denied udp 4.2.2.1(53) -> 96.235.180.xxx(54437), 1 packet DNS request timed out. timeout was 2 seconds. Sequence number 12 back in and there you go, I can resolve https://www.cnn.com. *July 20 18:23:56.138: %SEC-6-IPACCESSLOGP: list IN-FASTETHERNET0 permitted udp 4.2.2.1(53) -> 96.235.180.xxx(54438), 1 packet Non-authoritative answer: Name: https://www.cnn.com Addresses: 157.166.255.19 157.166.224.25 157.166.224.26 157.166.226.25 157.166.226.26 157.166.255.18 Not sure if this is an ISR vs regular router thing or what to be honest. Someone else might be able to shed some light on this little mystery. Herv fucked around with this message at 03:44 on Jul 21, 2009 |
|
#
?
Jul 21, 2009 03:41
|
|
|
ragzilla posted:NAT in most firewall/NAT devices is 'smart enough' to add create translations for UDP traffic passing through the device. The return traffic is permitted through for all protocols so long as it matches an existing translation/connection (by having implicit tcp established/udp established rules). The only thing you need a port forward for on these devices is for outside devices to be able to initiate a connection into your network. This is what I figured was happening and led to my comment about not needing a special ACL for DNS traffic; all my junk seems to be working just fine on my 871w.
|
|
#
?
Jul 21, 2009 04:21
|
|
|
code:more cisco fun: I've gotta configure a 1240 WAP in the morning. Is there much difference in configuring them to a 521? Tony Montana fucked around with this message at 11:18 on Jul 21, 2009 |
|
#
?
Jul 21, 2009 05:10
|
|
|
Herv posted:Not sure if this is an ISR vs regular router thing or what to be honest. Someone else might be able to shed some light on this little mystery. My gut feeling would be it's an 8xx series thing since they're more aimed at the SOHO space but I don't have one around the office to tinker with.
|
|
#
?
Jul 21, 2009 14:40
|
|
|
Let me just say, gently caress WINDOWS! I have been troubleshooting what appeared to be a lovely DS3 connection, getting only 8.5Mbps out of the full 45Mpbs. I tired to get the provider to run a BERT test via the line cards in the Cisco's for me, but eventually found out that the slowness is related to the TCP window size not scaling properly. When I force iperf to a 64K window I get the expected results, but Windows does not want to scale to the highest available setting on the remote end. I have found some inconsistencies with registy settings between two XP installs, and even some server installs. Some seem to have the RFC1323 settings there, others do not. Again, gently caress WINDOWS!
|
|
#
?
Jul 21, 2009 14:41
|
|
|
The lesson to take away from this is never, ever believe a server guy who says something is wrong with the network because his stuff is slow or doesn't work.
|
|
#
?
Jul 21, 2009 20:09
|
|
|
Heh. I feel your pain. That's why ISPs have demarcation points, makes everything so much easier.
|
|
#
?
Jul 21, 2009 20:42
|
|
|
Richard Noggin posted:Anyone familiar with SLAs on an ASA 5505? My SLA is working (somewhat), but the debug sla monitor trace command does not produce any results whatsoever. I'm waiting on the SmartNET info from the customer so I can call TAC, but wanted to see if anyone else has seen this. Just heard back from TAC - there's a yet-unresolved bug that requires you to first enter 'sh console-output': Cisco posted:CSCse57114 Bug Details Figured I'd throw this out there for anyone with the same problem.
|
|
#
?
Jul 21, 2009 21:23
|
|
|
|
| # ? May 30, 2024 07:05 |
|
|
inignot posted:The lesson to take away from this is never, ever believe a server guy who says something is wrong with the network because his stuff is slow or doesn't work. Unfortunately, the whole conversation usually goes something like this: "What's the connection between the datacenters?" "Uh, well it's about one-hundred megabits, give or take" "I'm only getting six megabits with this Windows file copy, something is wrong with the network" "Nope, something is wrong with your OS" "Blah blah blah I don't understand what you're saying" Later on: "Yeah, the network guys said it's just the way the network is, and there's nothing they can do about it" ~fin~
|
|
#
?
Jul 22, 2009 05:56
|
|