09-05-2013 01:09 AM - edited 03-04-2019 08:57 PM
Hi i'm running a DMVPN setup between a hub and spoke site and everything is working perfectly, at the hub the Cisco box is not the default gateway, we use another router for internet access and some other services so when traffic at the hub is destined for the spoke traffic is sent to the Gateway and forwarded to the cisco box and beyond and everything is working great.
The trouble is when traffic is sent from the spoke to the hub nothing except for ping is working unless I change the gateway on one of the hub servers to the cisco box then everything is once again ok, it also works fine just by adding a static route on the hub servers pointing to the cisco box for the spoke subnet.
The problem is i don't particularly want to setup static routes on each system at the hub to resolve this. I'm curious about this behaviour as ping still seems to work, i wondered if it was some sort of firewall issue but have yet to do any testing due to a lack of time? I'd appreciate if someone might shed some light on this.
thanks
Solved! Go to Solution.
09-05-2013 02:36 AM
Do I understand you right that you captured the traffic on the PC on the hub-site where you see the packets coming in but no responses leaving the PC? That would indicate a real strange PC-problem.
--
Don't stop after you've improved your network! Improve the world by lending money to the working poor:
http://www.kiva.org/invitedby/karsteni
09-05-2013 01:26 AM
The best way to solve this is to have a L3-switch between the end-devices and the gateways. With that you can controle the routing on the L3-switch.
With your scenario it seems like a problem with access-control on your internet-gateway. As if new sessions are allowed but return-traffic is dropped because the internet-gateway hasn't seen the initial request. ICMP could work in a scenario like that because it can be handled stateless. Can you log or debug the packet-processing on the internet-gateway to see what happens with the return-packets?
--
Don't stop after you've improved your network! Improve the world by lending money to the working poor:
http://www.kiva.org/invitedby/karsteni
09-05-2013 02:27 AM
Hey thanks for responding.
There are no dropped packets on the internet gateway. I setup a netmon session on a workstation at the hub and attempted to connect to an RDP session from the spoke site which failed, however RDP packets were received and recorded in netmon on the workstation at the hub site,
afterwards i added the static routes to the workstation at the hub and tested again, the connection successfully established and netmon recorded the packets as expected.
I can't really see anything in netmon indicating why the session failed without the static route in place? It is like the packets are being dropped but not by the gateways but by the local systems? It's like it is expecting the packets to come via the internet gateway but because it is not it drops it?
any other ideas?
thanks
09-05-2013 02:36 AM
Do I understand you right that you captured the traffic on the PC on the hub-site where you see the packets coming in but no responses leaving the PC? That would indicate a real strange PC-problem.
--
Don't stop after you've improved your network! Improve the world by lending money to the working poor:
http://www.kiva.org/invitedby/karsteni
09-05-2013 02:47 AM
Yes the packets were received at their final destination but there were also responses sent back to the client at the spoke its just the connection never establishes. This is the same with other traffic SMB etc. there seems to be full communication both ways but unless the static route is specified at the hub site no connection establishes.
There are a few semi suspicious outputs from netmon that do not appear when the static route is in place
they all either specificy the packet is a duplicate ack or it states (scale factor is not supported)
these types of packet are not present when a static route is specified? All these packets are directed from the hub workstation back to the RDP client at the spoke.
TCP:[Dup Ack #34]Flags=...A...., SrcPort=49240, DstPort=MS WBT Server(3389), PayloadLen=0, Seq=1414088605, Ack=501152362, Win=256 |
TCP:Flags=...A..S., SrcPort=MS WBT Server(3389), DstPort=63996, PayloadLen=0, Seq=835853522, Ack=2007309808, Win=8192 ( Scale factor not supported ) = 8192 |
09-05-2013 02:53 AM
Have the response-packets a destination-MAC-address of the Internet-gateway? I assume that based on a typical client-routing. But then the troubleshooting has to be continued at that gateway.
--
Don't stop after you've improved your network! Improve the world by lending money to the working poor:
http://www.kiva.org/invitedby/karsteni
09-05-2013 03:01 AM
Yes thank you for putting me on the right path, i was looking in the wrong direction.
the internet gateway is receiving part of a 3 way handshake and is dropping traffic back to the spoke. I need to see if i can stop this behaviour or maybe i'll have no choice but define static routes.
thanks for your help with this
09-05-2013 03:04 AM
But don't forget the option to put a L3-switch between the gateways and the endpoints. Perhaps your switch is already L3-capable?
--
Don't stop after you've improved your network! Improve the world by lending money to the working poor:
http://www.kiva.org/invitedby/karsteni
09-05-2013 04:11 AM
Hey,
I'm not entirely sure how an L3 switch would fit in to our scenario can you explain a bit further? Our current switches are not L3 and I would need strong arguments for further investment. As of now i've decided to add static routes to the hub computers through a script. It's not ideal but it will suffice until we replace the internet gateway with a more configurable device.
09-05-2013 04:29 AM
The IP-Address of the Internet-gateway would be moved to the L3-switch. Then you would add one or two more VLANs as transfer-networks between the L3-switch and the gateways. On The L3-Switch you have one default-route pointing to the internet-gateway and one or more static routes for your branches pointing to the DMVPN-router. The end-devices keep their default-gateway, but this time that points to the Switch. The PCs/Serves don't need any dedicated routes any more.
Perhaps there is another option:
Have your branches fixed IP-addresses? If yes, then you dont't need a default-route on the DMVPN-gateway. Host-routes to the spokes were enough. Then you could use the DMVPN-router als default-gateway and this router gets a new default-route to the internet-gateway.
--
Don't stop after you've improved your network! Improve the world by lending money to the working poor:
http://www.kiva.org/invitedby/karsteni
09-05-2013 08:37 AM
Hey,
the second option really interests me but, if i were to set a default route on the dmvpn gateway to the internet gateway would the router not attempt to establish the VPN through the internet gateway? One of the ideas behind the design was to seperate VPN traffic from internet traffic within the hub site.
thanks
09-05-2013 09:06 AM
That option will only work if your branches have fixed IPs. Then you can configure dedicated host-routes to reach the branches and the default-route points to the internet-gateway.
--
Don't stop after you've improved your network! Improve the world by lending money to the working poor:
http://www.kiva.org/invitedby/karsteni
09-06-2013 01:09 AM
Ok,
we do have fixed ip's i'll need to do a bit of research around host-routes because this is new to me.
thanks for the advice
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