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
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: