02-27-2014 09:02 AM - edited 03-11-2019 08:51 PM
Hi all,
I'm having a problem with ZBFW appearing to cause retransmits when connecting from an inside host to a host on the remote side of the DMVPN. ICMP appears to work fine, but RDP ends up with two sessions: one established and one half-open. When the half-open session times out, the connection dies.
What's interesting is that initiating a connection from a DMVPN host to an internal host, the connection gets established and I can stay connected all day with no problem. The router in question is a 7206vxr running 15.1(4)M7, and it serves as an internet edge router. All routes are present (EIGRP over DMVPN) and internet access is fine.
If I move the tunnel interfaces into the LAN security zone, no problem. Traffic flows from inside to outside. It's just when I have them into a separate zone, things get strange. I'm posting a sanitized config in case there's some glaring issue I've missed.
Output from 'sh policy-map type inspect zone-pair LAN-to-DMVPN sessions' when initiating an RDP session:
policy exists on zp LAN-to-DMVPN
Zone-pair: LAN-to-DMVPN
Service-policy inspect : LAN-to-DMVPN
Class-map: LAN-to-DMVPN (match-all)
Match: access-group name LAN-to-DMVPN
Inspect
Number of Established Sessions = 1
Established Sessions
Session 68AFD3A0 (192.168.77.160:3623)=>(172.23.2.13:3389) tcp SIS_OPEN/TCP_ESTAB
Created 00:00:09, Last heard 00:00:09
Bytes sent (initiator:responder) [0:0]
Number of Half-open Sessions = 1
Half-open Sessions
Session 68B027A0 (192.168.77.160:3623)=>(172.23.2.13:3389) tcp SIS_OPENING/TCP_SYNSENT
Created 00:00:09, Last heard 00:00:09
Bytes sent (initiator:responder) [0:0]
Class-map: class-default (match-any)
Match: any
Drop
0 packets, 0 bytes
Note the same source and destination pairs with different session IDs.
Now, when I connect from DMVPN to LAN via RDP:
policy exists on zp DMVPN-to-LAN
Zone-pair: DMVPN-to-LAN
Service-policy inspect : DMVPN-to-LAN
Class-map: DMVPN-to-LAN (match-all)
Match: access-group name DMVPN-to-LAN
Inspect
Number of Established Sessions = 1
Established Sessions
Session 68B051A0 (172.23.2.13:55622)=>(192.168.77.160:3389) tcp SIS_OPEN/TCP_ESTAB
Created 01:21:17, Last heard 00:00:00
Bytes sent (initiator:responder) [585503:10830828]
Class-map: class-default (match-any)
Match: any
Drop
2 packets, 40 bytes
Also note that this connection has been up for over an hour, and it does _not_ create the half-open session when the initial connect takes place.
Any ideas?
Thanks!
-P
02-27-2014 09:38 AM
Hello, Palmer.
ZBFW looks good; the only thing I could suggest to try is:
- rewrite ACL DMVPN-to-LAN without service "object-group RDP+SSH+ICMP" - write with "tcp ... eq 22/3389" stetements.
- or try to remove DMVPN to LAN pair (just to test).
02-27-2014 09:46 AM
Thanks Mikhailovsky,
I tested with the change to the ACL, but no luck. There isn't a problem from the DMVPN-to-LAN side - this works as expected, and the ACL shows hits either way it's configured.
The problem persists with LAN-to-DMVPN - one established and one half-open, and the connection dies when the half-open resets due to not receiving ACK SYN (but the established connection obviously completed 3-way handshake) - it's like something in the firewall config is causing the initial SYN to be retransmitted.
I've also tried with 15.2(4)M5 with no luck. Any other ideas?
Thanks!
-P
02-28-2014 02:35 AM
Hello, Palmer.
Try to remove DMVPN to LAN pair (just to test) - I suspect it could cause (on backtrack SYN) this weird session when TCP originated from LAN!
02-28-2014 07:55 AM
Mikhailovsky,
Still no dice. Didn't think it would affect the return traffic, but gave it a shot anyway. It's just baffling that ZBF is working as expected from DMVPN to LAN but the LAN to DMVPN traffic gets screwy. It's not just on RDP sessions, either - any interactive session I attempt to open dies out. I'm starting to wonder if it's got to do with NAT - that's the only difference in ingress traffic from the LAN side. I can probably simplify it by replacing the route-map with an ACL - there were initially two ISPs terminating on the router so the route-map was larger to identify different traffic sources
In the meantime - anything else you can think of? Anyone?
Thanks!
-P
03-02-2014 03:33 PM
Update:
I configured this on an 1811W running IOS 15(1)4 M7 and all was well. Must have been a problem with the hardware. Marking thus as answered - thanks for the replies.
-P
Sent from Cisco Technical Support iPad App
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide