|
You could just run ebgp everywhere.
|
#
?
Nov 26, 2021 16:04
|
|
|
|
| # ? Apr 20, 2024 03:22 |
|
|
NHS should be done on your ebgp speaking router. Idk your platform but on Junos you set NHS facing ibgp mesh. And sure you could literally run ebgp and ibgp without an igp but you'd have to configure it on each interface between everything and it becomes a management nightmare, even with only a handful of routers.
|
|
#
?
Nov 26, 2021 16:11
|
|
|
Ultimately you just need to account for the resolution of the next hop, and you have a variety of options. There's some healthy tension among different protocol choices vs. config size vs. templating/tooling
|
|
#
?
Nov 26, 2021 16:40
|
|
|
I did think about eBGP everywhere but the problem at the moment is the current design at this place is like a chain of ASA and Nexus contexts. So like; Core -> FW Context -> DC Switch -> DC FW Context -> DMZ Switch -> DMZ FW Context. I guess I could put same-zone switch and firewall contexts in its own ASN, then they'd only be a single iBGP peer at most, and two eBGP peers at most. It'll be much easier when I replace it with a single core firewall and have the switch contexts as zones off of the firewall. Then the FW could have its own AS, as well as each segment, but that'll won't be happening until after I need to get the initial design working. I'm not particularly worried about the config because it'll be done once, then again when we migrate firewalls, and it won't grow after that. We're moving almost everything to Azure so it'll being shrinking over time. I should also note there's no internet routes involved here. We don't have our own public AS so I just need to redistribute a default route for the internet. Also gently caress ASAs. Can't even lab this properly because they aren't VRF aware and if I put BGP on them it'll start advertising routes between VRFs. uhhhhahhhhohahhh fucked around with this message at 17:57 on Nov 26, 2021 |
|
#
?
Nov 26, 2021 17:36
|
|
|
uhhhhahhhhohahhh posted:Also gently caress ASAs. Can't even lab this properly because they aren't VRF aware and if I put BGP on them it'll start advertising routes between VRFs. Isnt EOL for ASAs rapidly approaching? Like sometime in 2022? Last I knew you could buy the new Firepower hardware and run ASA code on them still to buy you enough time to switch over to something besides a Cisco FW product.
|
|
#
?
Nov 27, 2021 02:48
|
|
|
The new code for the firepower devices have been working well. Finally integrates AnyConnect with Cisco Duo without going through a whole bunch of steps.
|
|
#
?
Nov 27, 2021 03:06
|
|
|
I've got an ASA with route based VPN configured to Azure, the ASA now has a failover WAN and I'm trying to figure out how to configure it to properly failover the tunnel. There is a default route pointing to outside1, I am monitoring this route so it will be pulled in the event the primary ISP goes down. Outside2 also has a static route configured with a higher cost than the above route, it takes over no problem when the primary ISP goes down. ASA has VTI1 configured and tied to outside1 with a static route pointing to that VTI for traffic that needs to hit Azure. Here's where I'm a bit stumped, if I create VTI2 and tie it to outside2 (and configure Azure accordingly), and then add a static route with a higher cost than the route mentioned above, how can I have the ASA pull the route for VTI1 out of the table? My initial thought was to monitor the other end of VTI1's tunnel, but I don't think that's going to work and unless I'm mistaken, even if the tunnel goes down, it will happily keep trying to use the VTI interface route since it's not a dynamic route. The only other thing I can think of is to implement BGP but that's going to create a big headache for me because it will lock me into having to deal with this until I leave this job because no one else will understand it. Part of the reason I haven't just done something is that I don't control the Azure instance, so it's better if I can just come up with the complete config for both sides and tell them what to configure once rather than playing around with it.
|
|
#
?
Nov 29, 2021 16:30
|
|
|
MF_James posted:I've got an ASA with route based VPN configured to Azure, the ASA now has a failover WAN and I'm trying to figure out how to configure it to properly failover the tunnel. If the tunnel goes down the logical interface should also go down.
|
|
#
?
Nov 29, 2021 17:08
|
|
|
Prescription Combs posted:If the tunnel goes down the logical interface should also go down. ok, so I'm overcomplicating this and it will actually down the interface and pull the VTI1 route out of the table? That's good.
|
|
#
?
Nov 29, 2021 17:32
|
|
|
In situations where I don't want to be roped into supporting something forever because people refuse to learn things I have been inclined to deploy virtual appliances that match whatever firewall is being used on-prem and then follow the manufacturer guidance for making VPN tunnels fail over. It's a waste of CPU and needlessly complicated as well as expensive, but if people aren't interested in learning small amounts of BGP or whatever then it's a viable alternative and it's not my money.
|
|
#
?
Nov 29, 2021 17:56
|
|
|
Thanks Ants posted:In situations where I don't want to be roped into supporting something forever because people refuse to learn things I have been inclined to deploy virtual appliances that match whatever firewall is being used on-prem and then follow the manufacturer guidance for making VPN tunnels fail over. It's a waste of CPU and needlessly complicated as well as expensive, but if people aren't interested in learning small amounts of BGP or whatever then it's a viable alternative and it's not my money. I would love to tell a client they need to pay microsoft even more money to link their azure instance to on-prem because our company has 2 "networking" people, one of which is my boss that has basically zero time to do technical stuff, and then me, while everyone else refuses to learn anything beyond "route outside 0.0.0.0 0.0.0.0 69.69.69.69 1". That's part of the reason I wanted to move away from policy based tunnels, because I'm used to route based from fortinet and they are easier for other people to understand and if changes need made you only have to mess with adding/removing routes instead of crypto maps and other poo poo.
|
|
#
?
Nov 29, 2021 18:20
|
|
|
Have you tried the Azure configuration yet with two routes pointing to the same local network using different local gateways? I always thought the only way to do this was to use BGP, but it's been about 2 years since I set the last one up like that. Assuming you're doing this: https://docs.microsoft.com/en-us/azure/vpn-gateway/vpn-gateway-highlyavailable#multiple-on-premises-vpn-devices
|
|
#
?
Nov 29, 2021 18:28
|
|
|
Thanks Ants posted:Have you tried the Azure configuration yet with two routes pointing to the same local network using different local gateways? I always thought the only way to do this was to use BGP, but it's been about 2 years since I set the last one up like that. Assuming you're doing this: Yeah, something I didn't realize is that Azure doesn't actually support active/passive only active/active.
|
|
#
?
Dec 1, 2021 18:45
|
|
|
Our Cisco rep just pinged us and said any new switch orders won't be fulfilled until late 2022. That's how bad supply chain issues are right now.
|
|
#
?
Dec 8, 2021 17:42
|
|
|
I'm going to see what I've got sitting around that functions still and get them on eBay, see who's desperate enough to buy a 10 year old PoE switch.
|
|
#
?
Dec 8, 2021 18:10
|
|
|
I have a stack of a dozen or so 2900 series and 3560-x series switches on the shelf.
|
|
#
?
Dec 8, 2021 18:23
|
|
|
GreenNight posted:I have a stack of a dozen or so 2900 series and 3560-x series switches on the shelf. Looks like 3560cgs are going for about $100 a pop! I have an old one thats just been sitting in my basement.... might be time to flip it.
|
|
#
?
Dec 8, 2021 18:35
|
|
|
poo poo aint cheap to ship though. Big box and heavy.
|
|
#
?
Dec 8, 2021 18:38
|
|
|
GreenNight posted:Our Cisco rep just pinged us and said any new switch orders won't be fulfilled until late 2022. That's how bad supply chain issues are right now. Yep. It's super bad. Who could have predicted that outsourcing all fabrication would have a negative effect on domestic supply chains? Oh well I'm sure a few thousand people were enriched by a few thousand billion dollars. So it's fine.
|
|
#
?
Dec 9, 2021 06:21
|
|
|
idk how anybody ever allowed 3/4 of the world's semiconductor manufacturing to land in Taiwan 50km off the coast of the China. A territory the CCP has spent the last 80 years saying it owns. When china finally hongkongs taiwan its definitely world war 3. (and the other quarter in mortar range of north korea) Methanar fucked around with this message at 07:08 on Dec 9, 2021 |
|
#
?
Dec 9, 2021 07:05
|
|
|
Yes but have you considered all the short term shareholder value that was created??? It’s fine the executives who signed off on it can afford to wait out the silicon wars from their lavish bunker on the moon or whatever.
|
|
#
?
Dec 9, 2021 14:56
|
|
|
Do most people do L3 routing on firewalls or the cores? Our network is setup to do it on the firewalls, so if you have any issues with them, your network is useless. When replacing a member of an HA pair doesn't go smoothly, for example. We swapped out a defective Fortinet last weekend and there were a couple minutes of downtime spread out across 2 hours and some monitoring data was lost, so fingers are being pointed.
|
|
#
?
Dec 9, 2021 20:04
|
|
|
Internal core here. The only internal traffic that would go through the firewall is traffic to/from the DMZ.
|
|
#
?
Dec 9, 2021 20:36
|
|
|
Depends on your traffic flows. If nothing really ever goes east-west then why would you bother?
|
|
#
?
Dec 9, 2021 20:46
|
|
|
Bob Morales posted:Do most people do L3 routing on firewalls or the cores? I typically try to push this to a firewall especially if it's a Fortinet; if your company is large enough you might need an east/west and north/south firewall, but I try to let switches stick to L2. The architect at my last job kind of engrained it in me and it seems preferable, having L3 on the switches (imo) is messy/complex and makes it tougher to throw more junior people at stuff. Like I can take a more junior admin and throw him at a L2 switch with minimal help, but if you add L3 stuff on there it gets a bit tougher for them and they require more help; then I can ease them into the L3 stuff on the firewall as it's containted there and the ACLs+routing make more sense.
|
|
#
?
Dec 10, 2021 03:12
|
|
|
Filthy Lucre posted:Internal core here. The only internal traffic that would go through the firewall is traffic to/from the DMZ. This is how I've always done it as well. You pay more money for L3 switches for a reason, let them handle routing as necessary.
|
|
#
?
Dec 10, 2021 05:34
|
|
|
BaseballPCHiker posted:This is how I've always done it as well. You pay more money for L3 switches for a reason, let them handle routing as necessary. Correct. Plus your firewall can do L3 routing at a handful of gigabits per second compared to what an L3 switch will do, which is generally wire rate across all ports. And this way, internal L3 traffic can't strangle the CPU of your edge firewall. The magic of ASICs!
|
|
#
?
Dec 10, 2021 05:41
|
|
|
If 100% of my traffic was ingress/egress, then putting the routing on the firewalls can makes sense. Ideally though the firewalls are running ECMP/BGP so that taking any given firewall out of commission for upgrades or whatever doesn't take down the whole DC. No don't put the firewalls into a cluster, that poo poo sucks. Have two standalone firewalls that are advertising specific /32s for whatever public services you are hosting. Those /32's will be advertised to your internet router(s) and the internet routers will advertise your public IP Blocks. If you want to save money you can have your edge routers be the same device as the core-routers and put the internet into a VRF so that all traffic has to transit a firewall.
|
|
#
?
Dec 13, 2021 19:51
|
|
|
ate poo poo on live tv posted:No don't put the firewalls into a cluster, that poo poo sucks 
|
|
#
?
Dec 13, 2021 20:25
|
|
|
I like how all my switches have dual power supplies but my firewall? gently caress no.
|
|
#
?
Dec 13, 2021 21:30
|
|
|
Sort of makes sense I think - you can’t do redundant access switches in a sane way, so power redundancy makes sense. But for things that can either work in HA or as a cluster or just play nicely when there’s more than one it’s good to just have two of them.
|
|
#
?
Dec 13, 2021 21:40
|
|
|
Or just put in 2 PSU's and save alot of work setting up HA and buying a second firewall.
|
|
#
?
Dec 13, 2021 21:43
|
|
|
GreenNight posted:Or just put in 2 PSU's and save alot of work setting up HA and buying a second firewall. And sell less firewalls and licenses? No... I don't think we'll be doing that.
|
|
#
?
Dec 13, 2021 23:13
|
|
|
Not a firewall guy. Certainly your firewall vendor if choice sells models with dual PSUs? My org uses Fortigate for firewalls currently, their 10g/SFP+ models tend to have dual PSU support.
|
|
#
?
Dec 13, 2021 23:22
|
|
|
We use Firepower, from the last time I looked the dual PSU one's were more than the cost of buying 3 regular firewalls.
|
|
#
?
Dec 13, 2021 23:24
|
|
|
On another note our Versa roll-out is going fairly well but multitenancy is a mindfuck in terms of configuring different elements in the right one. Also documentation is kinda poor and often you get better answers from the Juniper docs.
|
|
#
?
Dec 14, 2021 00:25
|
|
|
GreenNight posted:We use Firepower, from the last time I looked the dual PSU one's were more than the cost of buying 3 regular firewalls. We only have the 100f's and they have dual PSU's
|
|
#
?
Dec 14, 2021 14:36
|
|
|
So Meraki is having me install some pre-beta firmware on our stack of MS390's to try to fix the issue where the control plane keeps crashing, kicking it off the Meraki cloud. The fix? Auto reboot the control plane when it crashes. Not actually fixing the crash. Pray for me goons.
|
|
#
?
Dec 15, 2021 15:57
|
|
|
Anyone done PA FW deployments in Azure? Is it dumb of me to insist that all our subscriptions get their own interface on the VMs (and Loadbalancer - using the transit vnet design) to much better reflect and manage a Zone based segmentation/ZeroTrust deployment?? Also: does anyone else hate that the only deployment options in Azure are the typical HA pair deployment, which sucks, or two unpaired firewalls and then you have to deal with a bunch of Azure LB and NAT bullshit, which also sucks but for different reasons?? uhhhhahhhhohahhh fucked around with this message at 17:57 on Dec 24, 2021 |
|
#
?
Dec 24, 2021 16:12
|
|
|
|
| # ? Apr 20, 2024 03:22 |
|
|
The way we do it in AWS/GCP is I have all the traffic come in through a single Linux instance running FRR which is BGP Peered to however amount of firewalls we need for adequate throughput, and the FRR Router has interfaces in multiple routing tables. This allows us to avoid having to do source NAT on the palos. In AWS we have a lambda function that checks the FRR Router status and changed the route table if there's a problem, in GCP this is handled by the ILB. We've been running it like this for years without any major issue. The trade off is we had to abandon zone based rules in favor of subnet src/dst. You can also use a cloud plugin on the palos to do dynamic groups based on tags if you so desire. Sepist fucked around with this message at 19:02 on Dec 24, 2021 |
|
#
?
Dec 24, 2021 18:59
|
|
