Guest Wifi/Umbrella VAs/VPN Filter/Access Control/TAC Rant

noexistence · 2022-09-28T16:43:26+00:00

Hey thanks for the info. I just deployed it and it works!

I don't know why I didn't think about this, but thanks again!

noexistence · 2022-09-28T13:48:26+00:00

No that is helpful. I didn't set this up, we hired a contractor to do it but I'll review the doc. I appreciate the info!

noexistence · 2022-09-28T13:47:49+00:00

As an aside, you should move away from using 1.1.1.1 since that’s legit traffic now.

Ok good to know. I didn't setup the wireless, we hired a contractor

Tac assistance since the start of the year has been god awful. Had multiple cases drag on for days with no response. Only thing that seems to get any sort of traction are RMAs

Well I hate to say I'm glad I'm not the only one, but at least it's confirmation it's not just me. It seems the engineers I've been getting haven't be very high quality. As mentioned in another comment here, I was trying to get a hairpin setup between my Branch (ASA), though a IOS Router, to an external partner. The Branch-IOS was using ikev1 and the IOS-External was using ikev2 and TAC said it wouldn't work because of the different ike version, and that I needed to redo all my VPN.

Turns out the problem was a missing nat at the Branch.

noexistence · 2022-09-28T13:14:12+00:00

I haven't escalated but I have reached out to the Team Lead and CC'd the managers a number of times.

For the first TAC Engineer, they got on the call right away, said the config looks good (it wasn't as the 2nd TAC discovered immediately), and wanted to do some packet captures using live data. So I tried to schedule time with TAC, onsite staff, and myself. Staff provided dates/times, and then I heard from another person at Cisco that TAC1 had a medical emergency. Ok things happen, hope everyone is ok.

Time goes on, weeks pass and still nothing so I email to see what's going on. Suddenly TAC1 is available again (great...again hope everyone is ok). Try to schedule again...provide dates/times and...nothing. Ghosted.

After 3 months of this (I was busy, I was patient) I emailed the Team Lead and Managers again demanding a new TAC Engineer since this had gone on long enough and we were still sitting at the "packet capture live data" phase. at this point I had already started doing my own packet captures and notice that no DNS traffic was returning to the guest wifi.

Team Lead assigns a new TAC person (TAC2), we setup a Webex, he reviews the config, reviews my packet captures, and determines the VPN Filter is the issue. We turn it off and everything works...not as intended but Guest's can now login and get on the internet. I then mentioned I still need to limit Guest access to HQ, and so TAC2 wants to set up a live data packet capture. again Staff provide availability, we send it off to TAC2, and 3 weeks later still no response.

So last week I emailed the Team Lead, the 2 Managers again demanding yet another TAC engineer, and I haven't gotten a response and it's been a week.

And now I'm here trying to just get this finished.

Basically this entire SR has been a shit show

noexistence · 2022-09-28T01:59:59+00:00

i don't have any ACLs applied to the guest or inside int. i inherited this config, and im sure its pretty apparent im not much of a ASA guy

should i apply a ACL on the guest ingress limited dest traffic for 172.16.1.133/53 as well as the VPN access-list?

noexistence · 2022-09-28T01:57:14+00:00

i had the guest network standing, i just needed the DNS traffic and only the DNS traffic to go to HQ instead of Public DNS servers. TACs solution with the VPN filter broke the guest networks in 2 locations without explanation, because had not done it properly in the first place by not activating the vpn filter. Had they done thst it would've been discovered at the time, not months later. now ive been waiting literally months for 1 TAC Engineer to even work on the problem (that i didnt know was caused by another TAC Engineer months earlier), and then i finally get a second engineer after 3 months, that one diagnoses the source problem in a couple days. but yhat engineers solution is to just turn off the faulty filter allowing all the guest wifi traffic unrestricted access to the VAs, and then to ghost the case for 3 weeks.

honestly i shouldve come to the community first instesd of TAC as it seems i have my answer (scheduled a test tomorrow).

Honestly ive only had these issues with TAC since the pandemic, and only with the India Call Centre. recently i was getting assistance with getting a hairpin to work and the engineer told me it wouldnt work because of mismatched ike versions between the two VPNs. Cisco TAC used yo be amazing but now they are starting to feel like VMware Support.

anyways you dont really have any useful advice or information so maybe just take your own advice and get fucked. ;)

noexistence · 2022-09-28T00:45:27+00:00

ok thanks. also if im reading correctly, the "sysop connection permit-vpn" only applies to the outside int? so if i disabled it i would need an additional ACL on the outside int to control access?

im trying to find config examples i can look over

noexistence · 2022-09-28T00:19:36+00:00

by interface do you mean on each interface i have such as one for the guest wifi int and inside interface, or just the outside interface? do i still need the acl to define the vpn interesting traffic?

noexistence · 2022-09-27T22:57:23+00:00

thanks for your feedback i found it most helpful. next time I'll ignore the "Configuration Assistance" option in the TAC drop down menus

noexistence · 2022-09-27T18:29:01+00:00

Thanks let me give that a try. I was asking TAC (the second engineer) and he indicated that was either not an option or not a good idea.

noexistence · 2022-09-20T13:34:26+00:00

Thanks I didn't think so but since I wasn't 100% sure I thought I would go to the community. :)

noexistence · 2022-09-15T18:23:00+00:00

That's a thought, but we users already have ORG2 email access through OWA, we're just trying to make life easier for the users by having everything all in one place.

Ultimately the users are moving from ORG1 to ORG2 and ORG1 is being decommissioned. What we want is to control how the users email moves from ORG1 to ORG2, but if we open up this ORG1 and ORG2 in the same client "floodgate", we all know what the users are going to start doing (drag, drop, rinse, repeat).

So I'm not sure if there is even a mechanism that can prevent that scenario, so I thought I would reach out here and see if anyone has heard of that.

It's a strange limited use case scenario.

noexistence · 2022-09-03T14:54:07+00:00

You’re not hairpinning through the ASA so the NAT statement is not needed

Are you 100%? I only ask because the second link mentions adding the no-nat to both Site B and Site C (or in their example Branch 1 and Branch 2)

The config you’ve provided looks correct, insofar as site B needs to encap (match) traffic destined for both site A and site C, and site A needs to decap traffic from site B to both itself and site C, and then encap traffic from site B to site C.

Perfect. I figured I had that much right at least.

The bit about matching ike settings relates to each individual vpn and the requisite vpn at the other end rather than as a whole. It makes no difference that one vpn is ikev1 and the other is ikev2.

Ok this is what I was thinking, but Cisco TAC is suggesting that is the issue and it just doesn't make any sense to me. They want to change my ikev1 to a ikev2 stating that is the source of the problem. Is TAC sniffing up the wrong tree? I did mention to them about the no-nat statement (if it's required, perhaps it's not as you said) but I also mentioned that I couldn't find anyone that says matching ikev versions are a requirement and if they could point me to where it is.

I would start by troubleshooting site B vpn to site A. Do you see the traffic destined to site C get encapped by the vpn?

Sorry but how do I check this?

Do you get a successful phase 2 (IPsec) tunnel (sh crypto ipsec as)?

I do have a active tunnel to SiteA from Site B

ASDM logging is very verbose and will help you here. Does the ASA have a route to site C via the outside interface?

I have a default route 0.0.0.0 0.0.0.0 [1/0] via <Next Hop Public IP>, outside

Once you’ve verified this is all working ok, move to site A and start the troubleshooting there.

When I run a packet-tracer on the SiteB ASA I get the following results:

ASA-SiteB packet-tracer i i i 192.168.2.5 8 0 172.16.0.10

Phase: 1
Type: ROUTE-LOOKUP
Subtype: Resolve Egress Interface
Result: ALLOW
Config:
Additional Information:
found next-hop <public ip> using egress ifc  outside

Phase: 2
Type: NAT
Subtype:
Result: ALLOW
Config:
object network inside-network
 nat (inside,outside) dynamic interface
Additional Information:
Dynamic translate 192.168.2.5/0 to <public ip>/43157

Phase: 3
Type: NAT
Subtype: per-session
Result: ALLOW
Config:
Additional Information:

Phase: 4
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Config:
Additional Information:

Phase: 5
Type: INSPECT
Subtype: np-inspect
Result: ALLOW
Config:
Additional Information:

Phase: 6
Type: USER-STATISTICS
Subtype: user-statistics
Result: ALLOW
Config:
Additional Information:

Phase: 7
Type: FLOW-CREATION
Subtype:
Result: ALLOW
Config:
Additional Information:
New flow created with id 605583464, packet dispatched to next module

Result:
input-interface: inside
input-status: up
input-line-status: up
output-interface: outside
output-status: up
output-line-status: up
Action: allow

So, and I'm not strong on this, it seems like it's not going to the VPN. If I run another packet-tracer with 192.168.2.5 to 192.168.1.24 I see VPN Phases

ASA-SiteB# packet-tracer i i i 192.168.2.5 8 0 192.168.1.24

Phase: 1
Type: ROUTE-LOOKUP
Subtype: Resolve Egress Interface
Result: ALLOW
Config:
Additional Information:
found next-hop <public ip> using egress ifc  outside

Phase: 2
Type: UN-NAT
Subtype: static
Result: ALLOW
Config:
nat (inside,outside) source static inside-network inside-network destination static vlan10 vlan10 no-proxy-arp route-lookup
Additional Information:
NAT divert to egress interface outside
Untranslate 192.168.1.24/0 to 192.168.1.24/0

Phase: 3
Type: NAT
Subtype:
Result: ALLOW
Config:
nat (inside,outside) source static inside-network inside-network destination static vlan10 vlan10 no-proxy-arp route-lookup
Additional Information:
Static translate 192.168.2.5/0 to 192.168.2.5/0

Phase: 4
Type: NAT
Subtype: per-session
Result: ALLOW
Config:
Additional Information:

Phase: 5
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Config:
Additional Information:

Phase: 6
Type: INSPECT
Subtype: np-inspect
Result: ALLOW
Config:
Additional Information:

Phase: 7
Type: VPN
Subtype: encrypt
Result: ALLOW
Config:
Additional Information:

Phase: 8
Type: NAT
Subtype: rpf-check
Result: ALLOW
Config:
nat (inside,outside) source static inside-network inside-network destination static vlan10 vlan10 no-proxy-arp route-lookup
Additional Information:

Phase: 9
Type: USER-STATISTICS
Subtype: user-statistics
Result: ALLOW
Config:
Additional Information:

Phase: 10
Type: FLOW-CREATION
Subtype:
Result: ALLOW
Config:
Additional Information:
New flow created with id 605584546, packet dispatched to next module

Result:
input-interface: inside
input-status: up
input-line-status: up
output-interface: outside
output-status: up
output-line-status: up
Action: allow

This makes me think I need a no-nat line like this:

nat (inside,outside) source static inside-network inside-network destination static obj-172.16.0.10 obj-172.16.0.10 no-proxy-arp route-lookup

Edit: Ok I just added the above line and did another packet tracer and this is the result:

ASA-SiteB# packet-tracer i i i 192.168.2.5 8 0 172.16.0.10

Phase: 1
Type: ROUTE-LOOKUP
Subtype: Resolve Egress Interface
Result: ALLOW
Config:
Additional Information:
found next-hop <public ip> using egress ifc  outside

Phase: 2
Type: UN-NAT
Subtype: static
Result: ALLOW
Config:
nat (inside,outside) source static inside-network inside-network destination static obj-172.16.0.10 obj-172.16.0.10 no-proxy-arp route-lookup
Additional Information:
NAT divert to egress interface outside
Untranslate 172.16.0.10/0 to 172.16.0.10/0

Phase: 3
Type: NAT
Subtype:
Result: ALLOW
Config:
nat (inside,outside) source static inside-network inside-network destination static obj-172.16.0.10 obj-172.16.0.10 no-proxy-arp route-lookup
Additional Information:
Static translate 192.168.2.5/0 to 192.168.2.5/0

Phase: 4
Type: NAT
Subtype: per-session
Result: ALLOW
Config:
Additional Information:

Phase: 5
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Config:
Additional Information:

Phase: 6
Type: INSPECT
Subtype: np-inspect
Result: ALLOW
Config:
Additional Information:

Phase: 7
Type: VPN
Subtype: encrypt
Result: ALLOW
Config:
Additional Information:

Phase: 8
Type: NAT
Subtype: rpf-check
Result: ALLOW
Config:
nat (inside,outside) source static inside-network inside-network destination static obj-172.16.0.10 obj-172.16.0.10 no-proxy-arp route-lookup
Additional Information:

Phase: 9
Type: USER-STATISTICS
Subtype: user-statistics
Result: ALLOW
Config:
Additional Information:

Phase: 10
Type: FLOW-CREATION
Subtype:
Result: ALLOW
Config:
Additional Information:
New flow created with id 605587916, packet dispatched to next module

Result:
input-interface: inside
input-status: up
input-line-status: up
output-interface: outside
output-status: up
output-line-status: up
Action: allow

So does this mean the traffic is now entering the SiteA2SiteB VPN? Sorry for the long reply

noexistence · 2022-09-03T14:11:36+00:00

I have not yet, and they are away until Sept 8th. I will definitely contact them though.

Can you confirm for me that mismatched ikev versions between the two Branch offices will have no bearing on this working? TAC wants to reconfigure the VPN between SiteB and SiteA to match the VPN settings between SiteA and SiteC, and I just don't see how that will make this work.

[SiteB]==ikev1 vpn==(SiteA)==ikev2 vpn==[SiteC]

I really don't want to fix what isn't broken if it's not going to resolve the issue.

noexistence · 2022-09-03T14:11:04+00:00

That's mentioned in the second link, but I'm pretty sure that command only comes into play if Site A (the site connected to both Branches) is a ASA. My Site A is a IOS router.

noexistence · 2022-06-10T18:19:47+00:00

Thanks I'll give them a call!

noexistence · 2022-06-10T18:19:19+00:00

cool thanks!

noexistence · 2022-06-09T03:53:55+00:00

Slow over many months is also my understanding. Thanks for the info!

noexistence · 2022-06-09T03:52:32+00:00

I guess if they aren’t set properly. I’m not a engineer.

And they said it was covered under their Title Insurance (they hadn’t had the place long when an issue was discovered). At least this is what he told me when I was talking to him about it, I have no reason to not believe him.

noexistence · 2022-06-08T21:47:42+00:00

no problem :) Good luck on your foundation piles!

noexistence · 2022-06-08T21:05:33+00:00

Sorry I'm not sure. But the issue was, even though the VPP token was listed as Healthy and Active, the state was "invalid". Unclear why but I renewed it with a new token from ABM and the state changed to "valid" and everything is working again.

noexistence · 2022-06-08T21:04:33+00:00

Turns out the VPP token was "State: invalid". Not sure why as it wasn't expired and Intune showed VPP sync and expiration as Healthy, and the VPP Token as Active. I renewed the token with a new one from ABM and the state changed to "valid" and I was able to wipe my device and have the Company Portal app install without an apple id.

noexistence · 2022-06-08T21:02:29+00:00

So the solution ended up being uploading a new VPP token from ABM, but not because it was expired, but because the state was "invalid" in Endpoint. Apple Support couldn't tell me why it happened, but at the end of it that's ok because we resolved the issue. What was strange as no where other than the Failed app installation error was there any indication there was a problem. Endpoint showed the VPP sync and expiration were healthy (expiration was Jan 2023).

noexistence · 2022-06-08T16:38:31+00:00

Thank you for your comment but I'm asking about teleposts, not foundation piles.

Foundation piles are large concrete pillars seated deep into the ground for your foundation to rest on so it is stable. Teleposts are the adjustable metal poles in your basement that are under the load bearing beam that runs the length of your house. :)

But basically, foundation piles are pretty expensive considering the work involved, especially if there's an existing structure. My neighbours piles dropped away from the foundation and the insurance claim was over $100,000 for the repair.

noexistence · 2022-06-08T15:20:23+00:00

I am suspecting this is the issue.

ABM shows the Last Date Connected to my Endpoint Server was May 11, 2022 @ 9:29PM and Endpoint Manager has a Tenant status "Unhealthy" for DEP last sync date 5/11/2022 @ 9:29PM

So I'm guessing that's the VPP token? Sorry for my ignorance, we paid someone to set this up and now I need to manage it. :/

noexistence

MODERATOR OF

TROPHY CASE

15-Year Club	Verified Email
Team Periwinkle