|
Inspector_666 posted:Well he's a Cisco Certified Network Associate, not Cisco Certified Monitor Associate!
|
#
?
Aug 5, 2015 04:51
|
|
|
|
| # ? Apr 16, 2024 15:56 |
|
|
Unless it's a really old CGA monitor 
|
|
#
?
Aug 5, 2015 08:01
|
|
|
Partycat posted:
adorai posted:protip: VGA is DB-15 not DB-9. DB-9 is serial, and would be the correct port to use. Ugh I'm an idiot and should be fired. Out of a cannon. Into the sun.
|
|
#
?
Aug 5, 2015 14:15
|
|
|
adorai posted:protip: VGA is DB-15 not DB-9. DB-9 is serial, and would be the correct port to use. Pedantic tip: The modern standard VGA connector is actually DE-15 and serial is DE-9. DB is a wider connector, with the plain DB-25 variant being the one most of us will be familiar with from parallel ports, old Macs with external SCSI, and occasionally serial ports. Thanks Ants posted:Unless it's a really old CGA monitor EGA as well, and apparently some early VGA devices used DE-9.
|
|
#
?
Aug 5, 2015 14:38
|
|
|
Any quality, reliable third-party optics to look at as a less-expensive alternative to Cisco's SFP-10G-LR?
|
|
#
?
Aug 5, 2015 18:06
|
|
|
Richard Noggin posted:Any quality, reliable third-party optics to look at as a less-expensive alternative to Cisco's SFP-10G-LR? flexoptix
|
|
#
?
Aug 5, 2015 18:59
|
|
|
ragzilla posted:flexoptix Whoa, those are good prices. Thanks!
|
|
#
?
Aug 5, 2015 20:33
|
|
|
Has anyone ever had a problem with an ASA where it will respond to every ARP query and say that he owns the IP address in question. Because right now I have one that believes it owns every IP address not in 192.168.0.0/16
|
|
#
?
Aug 10, 2015 15:08
|
|
|
Methanar posted:Has anyone ever had a problem with an ASA where it will respond to every ARP query and say that he owns the IP address in question. Possibly a NAT statement causing proxy ARP.
|
|
#
?
Aug 10, 2015 15:16
|
|
|
psydude posted:I have an site to site VPN where one of the peers got moved from one provider to another, with a new public address. I updated everything on its peer, but for some reason it's failing Phase I with the message that there was no valid SA payload found and no valid tunnel group found on one side, while the other side is getting an invalid cookie message. I went so far as to delete the existing profiles and groups and use the wizard to rebuild them, to no success. I also tried adding the isakmp identity address command as mentioned in the support forums. Any ideas? Phase I was failing with the MM_WAIT_5 message. Found out the keys were mismatched, so I fixed that. Still receiving the same message, so I'm having the customer check for and disable NAT-T. After that, the only other thing I could find that would be breaking it would be a hash mismatch. . . 
|
|
#
?
Aug 10, 2015 18:06
|
|
|
Contingency posted:Possibly a NAT statement causing proxy ARP. How would I even begin to check something like that.
|
|
#
?
Aug 10, 2015 18:30
|
|
|
Methanar posted:How would I even begin to check something like that. Post your config
|
|
#
?
Aug 10, 2015 19:00
|
|
|
Methanar posted:Has anyone ever had a problem with an ASA where it will respond to every ARP query and say that he owns the IP address in question.  Let me tell you about a story of how 1 ASA took down nearly a whole butt in a data center because of a mis-configured NAT statement.manual NATs without declaring 'no-proxy-arp' at the end or not disabling it via sysopt is pretty hilarious in certain scenarios. sysopt noproxyarp <interface>
|
|
#
?
Aug 10, 2015 19:37
|
|
|
http://pastebin.com/PstpCMue
|
|
#
?
Aug 10, 2015 19:39
|
|
|
Betting it's any of the following lines depending on where 192.168.0.0/16 is actually configured. I couldn't find any references in the config you pasted to that subnet. nat (inside,any) source static any any destination static obj-172.16.25.0 obj-172.16.25.0 nat (inside,any) source static any any destination static obj-129.129.30.0 obj-129.129.30.0 nat (inside,any) source static any any destination static IPVPNClient IPVPNClient nat (dmz,outside) source static any any destination static obj-172.16.25.253 obj-172.16.25.253 nat (dmz,dmz) source static any any destination static obj-172.16.25.253 obj-172.16.25.253 Do you know if your ASA needs to proxy arp for anything? Possibly the 129.129.30.0 subnet?
|
|
#
?
Aug 10, 2015 20:06
|
|
|
Honestly I just think it might be a bug. Even with the configs totally wiped it still does it. There are no references at all to 192.168 in our network because we use some stupid non rfc 1918 subnet internally. Proxy arp shouldn't be used. I just thought I'd ask because Cisco hasn't been able to tell me anything either.
|
|
#
?
Aug 10, 2015 23:14
|
|
|
Methanar posted:Honestly I just think it might be a bug. Can you show us your arp table? Also how are you testing this? Is it possible your test is flawed?
|
|
#
?
Aug 10, 2015 23:20
|
|
|
ElCondemn posted:Can you show us your arp table? Also how are you testing this? Is it possible your test is flawed? I'm home now but the arp table is totally empty even after performing the test below. I tested it by unplugging all ethernet cables from the asa and my computer. Clearing all arp tables and wiping assigned addresses (they were infact cleared properly). Turn on wireshark. Address the ASA and my computer with static IPs in the 172.16.1.0/24 subnet, 192.168.1.0/24, 192.168.128.0/23 and 216.10.5.0/24 subnet as tests. Then plug in an ethernet cable from my computer to the ASA. This has been tested with multiple ASA ports and computers with the same results. It's also possible I am a complete idiot and my test means nothing. Wireshark will see arps being sent out asking if anyone has 172.16.1.1 or whatever address I gave my computer. The ASA will always respond that the mac address of the port I am plugged into already owns whatever IP I gave to my computer. With the exception of anything in 192.168.0.0/16. Methanar fucked around with this message at 00:05 on Aug 11, 2015 |
|
#
?
Aug 11, 2015 00:01
|
|
|
Methanar posted:I'm home now but the arp table is totally empty even after performing the test below. Was that your whole config? Do you have any DHCP entries in your config (helper ip or anything)? Any "ip local pool" sections? Can you do a show route?
|
|
#
?
Aug 11, 2015 00:09
|
|
|
ElCondemn posted:Was that your whole config? Do you have any DHCP entries in your config (helper ip or anything)? Any "ip local pool" sections? Can you do a show route? That was 90% of the config, I left out a bit of the VPN stuff which is unrelated and mostly just a list of the users. There is a little bit of DHCP just to address incoming VPN connections. They're given out from a pool of 172.16.25.240-250. Show route was empty when I tried it earlier today. These two static routes are really the only routing going on. The interfaces have ospf costs associated with them for no reason. We don't even have a routing protocol running. route outside 0.0.0.0 0.0.0.0 12.12.12.12 1 route inside 129.129.30.0 255.255.255.0 172.16.25.254 1 .
|
|
#
?
Aug 11, 2015 00:22
|
|
|
Methanar posted:That was 90% of the config, I left out a bit of the VPN stuff which is unrelated and mostly just a list of the users. I was hoping there was some kind of DHCP or routing issue. I'm stumped, I've never seen this kind of problem before, what happens when you disconnect everything from your ASA and connect it directly to your computer? Does it still have the same problem? I feel like it's got to be something outside of the ASA.
|
|
#
?
Aug 11, 2015 00:37
|
|
|
That's why it's so bizarre. The ASA has been sitting on my desk for like 4 weeks now and is brand new. It's never been used for real. I've been preparing it to be put into the network but it just absolutely refuses to let anyone else have an address. Being directly connected to my computer, and a few others just to troubleshoot, is all it's been.
|
|
#
?
Aug 11, 2015 00:43
|
|
|
psydude posted:Phase I was failing with the MM_WAIT_5 message. Found out the keys were mismatched, so I fixed that. Still receiving the same message, so I'm having the customer check for and disable NAT-T. After that, the only other thing I could find that would be breaking it would be a hash mismatch. . . ASA and hangs at MM_WAIT_5? I'd confirm you're actually receiving their PSK hash. "Show crypto isakmp 127" will allow you to follow the exchange packet by packet.
|
|
#
?
Aug 11, 2015 01:53
|
|
|
Methanar posted:That's why it's so bizarre. The ASA has been sitting on my desk for like 4 weeks now and is brand new. It's never been used for real. I've been preparing it to be put into the network but it just absolutely refuses to let anyone else have an address. I'm pretty certain it's your NAT lines. Try turning on sysopt noproxyarp. conf t sysopt noproxyarp inside sysopt noproxyarp dmz sysopt noproxyarp outside See if the behavior is still there. Those 'any any' references on the nats literally mean any address even if not in the config.
|
|
#
?
Aug 11, 2015 02:54
|
|
|
Prescription Combs posted:I'm pretty certain it's your NAT lines. I thought you were on the right track too, but it doesn't explain why only 192.168.0.0/16 is responding that way. I'd have to see a capture at this point to trust that he's interpreting the behavior correctly.
|
|
#
?
Aug 11, 2015 07:18
|
|
|
ElCondemn posted:I thought you were on the right track too, but it doesn't explain why only 192.168.0.0/16 is responding that way. I'd have to see a capture at this point to trust that he's interpreting the behavior correctly. Good chance that's the only interface he's tested with. Proxy ARP is expected behavior for the outside interface (and desired if multiple IPs on that interface are forwarded), and I don't recommend disabling it there. It's an ASA 5505. Should have rewritten the handful of rules instead of automigrating 8.2, as that just leads to headaches.
|
|
#
?
Aug 11, 2015 14:35
|
|
|
Contingency posted:ASA and hangs at MM_WAIT_5? I'd confirm you're actually receiving their PSK hash. "Show crypto isakmp 127" will allow you to follow the exchange packet by packet. If this is the case, what would be the likely cause of the issue?
|
|
#
?
Aug 11, 2015 15:34
|
|
|
psydude posted:If this is the case, what would be the likely cause of the issue? I was going to say the other side not having a PSK configured, but double checking shows 5 received a PSK hash from the initiator and sends its PSK hash in response. http://www.tunnelsup.com/isakmp-ike-phase-1-status-messages/ Does debug show the ASA sending its hash? If not, possibly incomplete tunnel group on your side. If debug shows a response from the originator to the effect of "malformed packet, possibly a PSK mismatch," obvious PSK mismatch. If you did send the hash, but receive no response, I'd ask for logs on their side to see where the breakdown is. I've never had to disable NAT-T (we just make NAT-free access a requirement). Does the debug indicate either side is behind a NAT device? Edit: Also, to get a better picture, try again with your side initiating to see where it breaks down. Can't count on theirs actually following the IPsec spec.
|
|
#
?
Aug 11, 2015 16:12
|
|
|
Looks like it's getting the "Can't find a valid tunnel group" message. Tunnel group is configured as the peer IP, isakmp identity is set to address, and the crypto maps match on either side.
|
|
#
?
Aug 11, 2015 16:57
|
|
|
Prescription Combs posted:I'm pretty certain it's your NAT lines. Shutting off proxy arp fixed the IP conflict issue I was having. Bad news is I'm stupid and shut it off for every interface and then tried to put it into the network. Since I have multiple publically addressed devices inside my network I must have proxy arp running for the outside interface and possibly the DMZ right? I broke the whole network for a good 90 minutes before I got everything back together.
|
|
#
?
Aug 11, 2015 17:11
|
|
|
Methanar posted:Shutting off proxy arp fixed the IP conflict issue I was having. Whoops. Yeah I'm used to a shared infrastructure environment that primarily does public > private NAT where public IPs generally don't reside behind the FWs. Since you have public address space across multiple interfaces you'll want to leave it enabled on those interfaces. A better workaround may be to disable it on the manual NAT lines that have the 'any any' as source and only identity NAT what you need with specific objects / object-groups.
|
|
#
?
Aug 11, 2015 18:34
|
|
|
Okay so I think I know why I've had such a hard time learning how to use a firewall. The configs I've been working with and trying to understand are horrible. I was always confused about the extra any any nat statements and I'm fairly sure they're completely useless now and Cisco agrees. I removed them all and turned proxy arp back on but I get the the IP conflict again.  Prescription Combs posted:primarily does public > private NAT where public IPs generally don't reside behind the FWs This would be the smart way of doing this.
|
|
#
?
Aug 11, 2015 20:34
|
|
|
Methanar posted:This would be the smart way of doing this.
|
|
#
?
Aug 12, 2015 04:56
|
|
|
psydude posted:Looks like it's getting the "Can't find a valid tunnel group" message. Crypto map bound to correct interface? When initiating from your side, does interesting traffic kickstart VPN initialization? If you post or PM me a sanitized copy of the ASA's "show run crypto" output, I can do a quick sanity check.
|
|
#
?
Aug 12, 2015 06:39
|
|
|
I didn't understand why my configs' nat rules were using Inside,Any so I changed them all to Inside,Outside for fun. This fixed my issue of the asa believing it owned every IP without having to turn off proxy arp. Can someone smarter than me tell me what I did?
|
|
#
?
Aug 13, 2015 02:47
|
|
|
Methanar posted:I didn't understand why my configs' nat rules were using Inside,Any so I changed them all to Inside,Outside for fun. You told it to only NAT traffic that was going from the inside to the outside, instead of all traffic originating from the inside.
|
|
#
?
Aug 13, 2015 03:13
|
|
|
Well, yeah. But how could that be fixing the issue I was having of the ASA claiming every address was in use on behalf of non existant devices behind nat?
|
|
#
?
Aug 13, 2015 04:25
|
|
|
Methanar posted:Well, yeah. Let's say you have a /29, with 5 hosts usable--1.2.3.2-6. 1.2.3.1 is the upstream router. ASA is assigned 1.2.3.2. On the ASA, you forward 1.2.3.3 and 1.2.3.4 to internal hosts. When traffic destined for 1.2.3.4 exits the router interface, that traffic isn't magically forwarded to your internal hosts. The ASA ARPs not only for 1.2.3.2, but also proxy ARPs for 1.2.3.3 and 1.2.3.4. The traffic is then received by the ASA and unNAT'd to your internal hosts. The ASA was doing this for your internal interface because of how your NAT rules were configured.
|
|
#
?
Aug 13, 2015 04:41
|
|
|
Contingency posted:Let's say you have a /29, with 5 hosts usable--1.2.3.2-6. Okay I followed that. So what are legitimate uses of natting to any interface assuming you have more than inside and outside? Should you ever use any or always specifically choose interfaces.
|
|
#
?
Aug 13, 2015 05:19
|
|
|
|
| # ? Apr 16, 2024 15:56 |
|
|
Methanar posted:Okay I followed that. NoNAT statements would probably be the best use case, and only in scenarios with more than one internal interface configured. By default, the ASA uses NAT divert to route traffic out the correct egress interface (even ignoring the route table), so if you have a matching inside,outside rule configured it's going inside whether you want it to or not. Configuring "any" instead of the specific interface will prevent this behavior, but it'd be smarter to disable NAT divert on the rule instead.
|
|
#
?
Aug 13, 2015 05:35
|
|