|
Powercrazy posted:Also who cares if someone wants full tables? It doesn't cost you anything. Memory in your PE. TCAM slots if you can't do BGP RIB to FIB filtering. But yeah, the ability to give a customer full routes should pretty much be standard if you're providing transit services. The only excuse would be if you're single homed and static routed to your transit.
|
#
?
Aug 22, 2014 01:40
|
|
|
|
| # ? Apr 20, 2024 04:40 |
|
|
hah geez, I should have given more context: I'm in Australia and 95% of our customers are small IT shops that are single or dual homed to our PoPs advertising a single /22 (or /23's or /24's if they're feeling saucy) and providing Internet access and VPNs to small domestic-only businesses. They rely on us to give them advice so that is what we do, the advice we most often dispense is that they do not need full tables and explain what full tables are useful for and the impact taking full tables will have on their (usually low end) hardware. Edit: we don't even take full tables ourselves (although we easily could) because we don't need them.
|
|
#
?
Aug 22, 2014 01:48
|
|
|
I did it. I finally finished reading all 300 pages of this thread over the course of 8 months (Jesus). Does anyone have a handy "VPN for Dummies" guide they learned from or use as a reference? I got by at my last job for four years configuring site-to-site tunnels on Cisco ASAs via saved templates. While I pray that I never have to configure another one, I'd like to at least learn how a site-to-site tunnel authenticates, what kinds of key exchanges exist, what PFS is, what isakmp is, and how it all fits together really. According to Amazon reviews the actual "VPN for Dummies" book isn't very good.
|
|
#
?
Aug 22, 2014 04:53
|
|
|
Partycat posted:So something's up and I don't know what it is yet. It looks like all the SIP traffic from the CUBE is process switched and punted from CEF. It's all working, but that stack instantly draining to 0 is sort of not good looking.
|
|
#
?
Aug 22, 2014 14:05
|
|
|
funk_mata posted:
Cisco has so many different ways to implement a vpn that the technology is bottomless. I mean, look at this: http://www.ciscopress.com/search/index.asp?query=vpn
|
|
#
?
Aug 22, 2014 15:22
|
|
|
inignot posted:Cisco has so many different ways to implement a vpn that the technology is bottomless. I mean, look at this: And even when you decide on a VPN type, then there's a million ways to do each one. For example DMVPN: http://www.cisco.com/c/dam/en/us/products/collateral/security/dynamic-multipoint-vpn-dmvpn/DMVPN_Overview.pdf
|
|
#
?
Aug 22, 2014 22:19
|
|
|
While we're on the topic of VPNs, is there any way to create a VPN tunnel between two routers, one of which is has a public IP but the other which is NATted behind a firewall? Ideally I'm thinking the NATted router would reach out to the one with the public IP to establish communication because I'm not sure how it would work any other way. Anyway, not even sure if this is a thing that's possible or if it's a crazy question. VPNs are easily my weakest networking subject. Basically one of my clients has a Fortigate in office space that he's leasing from someone, but the space sells its own "internet" which is just a business line with 1 IP which the office then VLANs out behind one router to its leasees. He'd like to VPN back to a central office however and establish two way communication. I'm less concerned whether the fortigate can do this and more whether it's even possible at all. I can get them to switch vendors if it's too hard to do with the FG. some kinda jackal fucked around with this message at 01:25 on Aug 23, 2014 |
|
#
?
Aug 23, 2014 01:22
|
|
|
Martytoof posted:While we're on the topic of VPNs, is there any way to create a VPN tunnel between two routers, one of which is has a public IP but the other which is NATted behind a firewall? Ideally I'm thinking the NATted router would reach out to the one with the public IP to establish communication because I'm not sure how it would work any other way. NAT-T can do this. https://supportforums.cisco.com/document/64281/how-does-nat-t-work-ipsec Site A has the public IP. Site B has the VPN peer NAT'd behind a firewall. For both sides to be able to initiate, Site B would require a static, public IP on their firewall which in turn port forwards UDP 500/4500 to the VPN peer.
|
|
#
?
Aug 23, 2014 02:35
|
|
|
Martytoof posted:While we're on the topic of VPNs, is there any way to create a VPN tunnel between two routers, one of which is has a public IP but the other which is NATted behind a firewall? Ideally I'm thinking the NATted router would reach out to the one with the public IP to establish communication because I'm not sure how it would work any other way. It can in theory be done with the Fortigate, but requires some CLI interaction and can't be done in the GUI (when we were trying about a year ago) We never got it working, but doing it on a Cisco ISR it's painless.
|
|
#
?
Aug 23, 2014 02:38
|
|
|
less than three posted:It can in theory be done with the Fortigate, but requires some CLI interaction and can't be done in the GUI (when we were trying about a year ago) Thanks, both of you. If it can be done then I don't mind digging into the lovely Fortigate CLI to do it -- just wanted some verification that I could do it without port forwarding anything on the office complex firewall which I don't have any access to.
|
|
#
?
Aug 23, 2014 03:25
|
|
|
inignot posted:Cisco has so many different ways to implement a vpn that the technology is bottomless. I mean, look at this: less than three posted:And even when you decide on a VPN type, then there's a million ways to do each one. Thanks. It sounds like debugging, troubleshooting, and studying a specific vendor's implementation (Cisco's IPSec VPN on a Cisco ASA for instance) may be the best way to start. Partycat posted:It looks like all the SIP traffic from the CUBE is process switched and punted from CEF. It's all working, but that stack instantly draining to 0 is sort of not good looking. Interesting. Is it a 2921?
|
|
#
?
Aug 23, 2014 05:00
|
|
|
Partycat posted:It looks like all the SIP traffic from the CUBE is process switched and punted from CEF. It's all working, but that stack instantly draining to 0 is sort of not good looking. Wouldn't that be expected in a CUBE config? Iirc it terminates the SIP/H323 on either side and acts as a proxy (for the control packets) acting as an SBC. Media should go direct to/from DSPs in the fast path.
|
|
#
?
Aug 23, 2014 05:31
|
|
|
funk_mata posted:Thanks. It sounds like debugging, troubleshooting, and studying a specific vendor's implementation (Cisco's IPSec VPN on a Cisco ASA for instance) may be the best way to start. Yes, 2921. RTP is not seen in that path so that was expected.
|
|
#
?
Aug 23, 2014 13:06
|
|
|
Martytoof posted:Thanks, both of you. If it can be done then I don't mind digging into the lovely Fortigate CLI to do it -- just wanted some verification that I could do it without port forwarding anything on the office complex firewall which I don't have any access to. I think port forwarding is required, as IPsec uses UDP packets so it'll be stateless to the firewall. I was just saying there was a way for the Fortigate to IPsec with a Cisco device.
|
|
#
?
Aug 24, 2014 06:17
|
|
|
less than three posted:I think port forwarding is required, as IPsec uses UDP packets so it'll be stateless to the firewall. I was just saying there was a way for the Fortigate to IPsec with a Cisco device.
|
|
#
?
Aug 24, 2014 14:13
|
|
|
ragzilla posted:Memory in your PE. TCAM slots if you can't do BGP RIB to FIB filtering. unggh yeah keep going.
|
|
#
?
Aug 25, 2014 00:17
|
|
|
funk_mata posted:I did it. I finally finished reading all 300 pages of this thread over the course of 8 months (Jesus). Congratulations on reading the entire thread! You're probably the one person that did. If you want to just learn the fundamentals, you may want to spin up two linux VMs (or whatever) running openswan / strongswan, and screw around with that. It's miles away from the Cisco configuration, but you'll be able to look at the phase 1 and phase 2 parameters, and see how they work (or usually don't work). You could also spin up two crypto enabled IOS images under dynamips, and play with that. The most important things to know, at least, from my experience, are: 1). IKE and ISAKMP aren't really the same thing, but they're often used interchangeably by vendors/customers/partners/supposedly smart people. This is usually not a problem, since ISAKMP, though older, is practically a modern colloquialism for IKE. Don't blame me, I only work here. 2). If it's not working, it's almost always either a transform set mismatch, or a security association disagreement. If it's still not working, it's still a transform set or security association disagreement. If it's not working after that, it's an ACL issue. 3). Don't build your tunnels to rfc 1918 space, even though the other party is saying it's their only option, and that "other people do it," and that "we have to have this running today/tomorrow/this year". It'll end in heartache. 4). A lot of platforms will claim things like, "500,000 VPN tunnels!" when in reality, they mean 500,000 security associations. One tunnel could have a handful of security associations, depending on what you're doing.
|
|
#
?
Aug 25, 2014 21:29
|
|
|
jwh posted:3). Don't build your tunnels to rfc 1918 space, even though the other party is saying it's their only option, and that "other people do it," and that "we have to have this running today/tomorrow/this year". It'll end in heartache. I think I may be misunderstanding what you're saying here. Are you recommending that tunnels be created with internet route-able address space?
|
|
#
?
Aug 26, 2014 00:58
|
|
|
CaptainGimpy posted:I think I may be misunderstanding what you're saying here. Are you recommending that tunnels be created with internet route-able address space? My company does this--I'd say about third or so of our customers have a network in the 192.168.1.0/24 subnet. We make our customers present themselves as a public IP, or if that's not possible, a private IP from a range we set aside. This works out well, except that it often takes a week or more for techs to set up their end. My predecessor didn't always enforce this policy, and 300 VPNs later, the workarounds to workarounds to keep things communicating are a mess. If it's a branch office<>main office VPN, you'll be better off with a subnet<>subnet connection rather than NATting one or both sides.
|
|
#
?
Aug 26, 2014 01:48
|
|
|
jwh posted:2). If it's not working, it's almost always either a transform set mismatch, or a security association disagreement. If it's still not working, it's still a transform set or security association disagreement. If it's not working after that, it's an ACL issue. I'm a Cisco IOS/networking scrub yet I agree with this advice 1000%. If your tunnel doesn't come up it's almost always due to a phase 1 proposal mismatch. Also I've read the entire thread, albeit starting over 6 months ago! Good advice all round.
|
|
#
?
Aug 26, 2014 14:32
|
|
|
CaptainGimpy posted:I think I may be misunderstanding what you're saying here. Are you recommending that tunnels be created with internet route-able address space? I should clarify, if you're building tunnels to other organizations, such as partners, vendors, customers, etc., and you don't control their address space, then don't agree to use rfc1918 space. It'll bite you later on. If you control the addressing then of course you can use whatever you like (including rfc1918). But with other organizations, it's always been a problem, in my experience.
|
|
#
?
Aug 26, 2014 21:49
|
|
|
jwh posted:2). If it's not working, it's almost always either a transform set mismatch, or a security association disagreement. If it's still not working, it's still a transform set or security association disagreement. If it's not working after that, it's an ACL issue. Agreed. It's also important to remember what information is available at which phase of the process. Phase 1 (IKE): Public IP, Preshared Key, Phase 1 proposal / transform set (and outgoing interface). If you're failing in Phase 1, it's one of the above items. Phase 2 (IPSEC): Private IPs (both sides), Phase 2 proposal / transform set. If you're failing in Phase 2, it's one of the above items. If you're completing Phase 1, you don't need to keep checking the preshared key, since it's already good to go.
|
|
#
?
Aug 26, 2014 22:12
|
|
|
Apparently IOS can do phase 1 authentication with plain RSA keys, which you generate anyway to enable SSH. Why does every organization I've been asked to set up a VPN with still insist on using pre-shared keys with 3DES encryption in 2014?
|
|
#
?
Aug 26, 2014 22:42
|
|
|
SamDabbers posted:Apparently IOS can do phase 1 authentication with plain RSA keys, which you generate anyway to enable SSH. Why does every organization I've been asked to set up a VPN with still insist on using pre-shared keys with 3DES encryption in 2014? For all of my internal VPNs I use RSA keys. Interfacing with a third party? Pretty sure I know they will know how to use a plain text PSK and it'll work in 5 minutes.
|
|
#
?
Aug 27, 2014 00:20
|
|
|
RSA key pairs would have to be generated & shared for every VPN endpoint. Good luck doing that on something like DMVPN. Also you can encrypt the preshared key inside the router config so it's non readable.
|
|
#
?
Aug 27, 2014 02:10
|
|
|
SamDabbers posted:Apparently IOS can do phase 1 authentication with plain RSA keys, which you generate anyway to enable SSH. Why does every organization I've been asked to set up a VPN with still insist on using pre-shared keys with 3DES encryption in 2014? pre-shared is easier and therefore better in almost all circumstances.
|
|
#
?
Aug 27, 2014 02:57
|
|
|
jwh posted:I should clarify, if you're building tunnels to other organizations, such as partners, vendors, customers, etc., and you don't control their address space, then don't agree to use rfc1918 space. It'll bite you later on. Got it. We dictate that stuff in contracts when we setup VPN's. If they can't figure out how to handle it on their end, we do it on ours. We use the 172.16/12 range. 9 times out of 10 that's fine. We also got a VPN concentrater so NAT'ing was easier. Now, that took me 2 years and a lot of whining to get that done.
|
|
#
?
Aug 27, 2014 19:55
|
|
|
CaptainGimpy posted:Got it. We dictate that stuff in contracts when we setup VPN's. If they can't figure out how to handle it on their end, we do it on ours. We use the 172.16/12 range. 9 times out of 10 that's fine. We also got a VPN concentrater so NAT'ing was easier.
|
|
#
?
Aug 28, 2014 00:23
|
|
|
I've got a hub and spoke set up of 4 remote offices and one hub office, all connected back to the hub via separate L2 ISP ethernet links. Right now I have each of the remote site's vlans trunked back to the central switch at the hub office, and it handles the routing between locations. Every office has a different vlan/broadcast domain for their lan, BUT the central switch has all of their vlans on it. I am thinking this is not a best practice and that a transit VLAN would be better. The problem is, when I do this with a transit VLAN, I lose the ability to port forward from our firewall, to the devices on the remote offices LANs. Right now it looks like: Internet---->Sonicwall----->Hub Core Switch------>Remote Switch------->Device But even though my sonicwall can route to the subnets on "Remote Switch", it can't NAT to them. Do I need a switch capable of doing NAT as well? Or should this be working directly from the firewall to the remote lan?
|
|
#
?
Aug 28, 2014 17:02
|
|
|
It should work fine, provided the sonicwall knows how to reach those remote subnetworks.
|
|
#
?
Aug 28, 2014 20:23
|
|
|
adorai posted:I've been using vyos (previously vyatta) for all of our IPsec tunnels because it's very easy to NAT traffic and troubleshoot problems when they do occur. Our fortigate is pretty good about it, but not great. How VyOS treating you? Is it still strictly CLI or did they pull together a gui of some sort? I prefer CLI myself but the boss likes pretty graphs.
|
|
#
?
Aug 30, 2014 07:44
|
|
|
CrazyLittle posted:How VyOS treating you? Is it still strictly CLI or did they pull together a gui of some sort? I prefer CLI myself but the boss likes pretty graphs.
|
|
#
?
Aug 30, 2014 13:19
|
|
|
And surely it exposes SNMP so you can roll your own pretty graphs in whatever tool you like.
|
|
#
?
Aug 31, 2014 17:06
|
|
|
Docjowles posted:And surely it exposes SNMP so you can roll your own pretty graphs in whatever tool you like. Yeah, again it's not for my benefit considering I already graph all my (brocade lol) Vyatta and Ubiquiti devices with cacti. ... Because a pretty GUI is somehow the thing that makes it acceptable to replace Cisco. *cough* By the way: if you do want supported-Vyatta, Brocade's internal site is garbage for finding Vyatta documentation, but at least they kept all the senior techs on board so there's still a team of humans who know what they're doing.
|
|
#
?
Aug 31, 2014 18:04
|
|
|
CrazyLittle posted:Brocade
|
|
#
?
Aug 31, 2014 19:37
|
|
|
jwh posted:If you want to just learn the fundamentals, you may want to spin up two linux VMs (or whatever) running openswan / strongswan, and screw around with that. It's miles away from the Cisco configuration, but you'll be able to look at the phase 1 and phase 2 parameters, and see how they work (or usually don't work). Thanks. I'd heard of and forgotten about OpenSwan. If it provides clear logging/debugging of what's going on I'll give it a shot. jwh posted:3). Don't build your tunnels to rfc 1918 space, even though the other party is saying it's their only option, and that "other people do it," and that "we have to have this running today/tomorrow/this year". It'll end in heartache. Seconded. My last gig ran into these issues and the resolutions were all miserable. inignot posted:RSA key pairs would have to be generated & shared for every VPN endpoint. Good luck doing that on something like DMVPN. Also you can encrypt the preshared key inside the router config so it's non readable. Correct me if I'm wrong, but isn't the article SamDabbers linked to arguing that you only need to give the far-end your public key instead of generating a new pair for each endpoint?
|
|
#
?
Sep 2, 2014 16:13
|
|
|
funk_mata posted:Correct me if I'm wrong, but isn't the article SamDabbers linked to arguing that you only need to give the far-end your public key instead of generating a new pair for each endpoint? Yes, you can reuse the same public key that you generate anyway to enable SSH on IOS. The article actually says that a full PKI with certificates is better for cases like DMVPN, since manually configuring each peer's public key on every other peer would be a management nightmare with just a handful of routers. It's only PSKs that should be unique for each VPN link, and the biggest weakness of using PSKs is when multiple peers have dynamic addresses, since all dynamic peers would have to use the same PSK in that case due to how IKE works. Aside from the "random IT person at the other end will more likely understand PSKs" reason, using public keys for one-off point-to-point VPN links seems more secure and about as simple to configure (judging by the example config) as a PSK if both sides support it. SamDabbers fucked around with this message at 16:34 on Sep 2, 2014 |
|
#
?
Sep 2, 2014 16:32
|
|
|
funk_mata posted:Thanks. I'd heard of and forgotten about OpenSwan. If it provides clear logging/debugging of what's going on I'll give it a shot. Oh don't worry, it doesn't.
|
|
#
?
Sep 2, 2014 16:47
|
|
|
jwh posted:Oh don't worry, it doesn't. I'ma let you finish, but Racoon has the most useless log messages of all IKE implementations.
|
|
#
?
Sep 2, 2014 16:50
|
|
|
|
| # ? Apr 20, 2024 04:40 |
|
|
Despite relatively straightforward logging, I've nearly plucked my head bald debugging a few IKE problems on various Fortigates over the past few weeks. I've got a handful of old 100As that I'm reusing as endpoints for my own lab network at various sites to my 60D at home, and unless there's something horribly broken when trying to establish P1 between a 4.0-latest (yeah yeah, old 100As, remember?) and 5.2-latest FortiOS then I don't even know what...
|
|
#
?
Sep 3, 2014 01:59
|
|