Routed network does forward icmp but not http

Hello everyone,

I just build a vpn setup that terminates into a Watchguard device.
The setup looks as follows.

  1. The VPN Client (RB751G) connects to the VPN Server which has the IP Address 212.53.XXX.XXX
  2. The VPN Client obtains a tunnel IP (local & remote) of 10.1.30.3 (local) and 10.1.30.1 (remote)
  3. All traffic that is produced by clients connected to the VPN Client get routed out of the sstp-out interface
  4. The VPN Server ist connected to the Watchguard with the IP address 10.10.0.2, while the Watchguard has the IP 10.10.0.1
  5. All traffic coming from the VPN Client with the IP address 10.1.30.3 to the VPN server is routed from the VPN Server to the Watchguard (10.1.30.0/24 to 10.10.0.1 on interface ether1)

So far so good, the funny thing is everything seems to be setup just fine bute the only traffic i can push through this construct ist icmp. I can see http traffice traversing the interface to the watchguard but it doesn’t reach the VPN Client. I am missing something but i don’t know what.

/ip firewall nat
add action=dst-nat chain=dstnat disabled=yes src-address=10.1.30.0/24 \
    to-addresses=10.10.0.1
add action=masquerade chain=srcnat src-address=10.1.30.0/24 to-addresses=\
    10.10.0.1
add action=masquerade chain=srcnat dst-address=10.1.30.0/24



/ip firewall mangle
add action=mark-routing chain=prerouting dst-address=0.0.0.0/0 \
    new-routing-mark=vpn
add action=mark-routing chain=prerouting in-interface=ether1-Watchguard-egress \
    new-routing-mark=vpn-out src-address=0.0.0.0/0
add action=mark-routing chain=prerouting new-routing-mark=vpn src-address=\
    10.1.30.0/24
add action=mark-routing chain=prerouting dst-address=10.1.30.0/24 \
    new-routing-mark=vpn-out



/ip route
add distance=1 dst-address=10.1.30.0/24 gateway=10.10.0.1 routing-mark=vpn
add distance=2 gateway=212.53.XXX.XXX
/ip route rule
add routing-mark=vpn table=vpn



 #      DST-ADDRESS        PREF-SRC        GATEWAY            DISTANCE
 0 A S  10.1.30.0/24                       10.10.0.1                 1
 1 A S  0.0.0.0/0                          212.53.151.1              2
 2 ADC  10.1.30.3/32       10.1.30.1       <sstp-test>               0
 3 ADC  10.10.0.0/24       10.10.0.2       ether1-Watchgua...        0
 4 ADC  172.16.30.0/24     172.16.30.6     local-bridge              0
 5 ADC  212.53.XXX.XXX/XX    212.53.XXX.XXX   ether2-gateway            0



 #   ADDRESS            NETWORK         INTERFACE                                
 0   212.53.XXX.XXX/XX   212.53.XXX.XXX    ether2-gateway                           
 1   172.16.30.6/24     172.16.30.0     ether8-vpn-gateway                       
 2   10.10.0.2/24       10.10.0.0       ether1-Watchguard-egress                 
 3 XI 212.53.XXX.XXX/XX   212.53.XXX.XXX    ether7-failover-gateway                  
 4 D 10.1.30.1/32       10.1.30.3       <sstp-test>

When you make a TCP connection, do you get a connection that later gets stuck (no data), or is the connection
not established at all?

The connection gets established I can see it when I torch the interface that faces the Watchguard but the client doesn’t receive the replies.

Then it is a MTU problem, usually combined with bad firewall configuration.
You need to make sure that ICMP is not dropped.
But it usually does not hurt to add a “clamp MSS to PMTU” rule for protocol TCP in the mangle table.

To see what value of MTU is the problem just ping with larger packets and watch when it stops working.

Ok, how would i set this rule? I have never done that before.

Edit: ICMP packets are the only ones that can traverse the network, everything else gets lost at the VPN server.

It stops after a packet size of 1500.

The way to insert such a rule would be:

/ip firewall mangle
add action=change-mss chain=forward new-mss=clamp-to-pmtu protocol=tcp tcp-flags=syn

Paste this in a terminal window.
It is not necessary in a network where everything w.r.t. ICMP processing works OK, but unfortunately that
is often not the case.
It may be that you need to do a similar thing inside the VPN server.

Ok, I’ve put it in the config but it didn’t have the desired effect. The problem still exists. ICMP works, TCP doesn’t.

Then you can change it from “clamp to PMTU” into some fixed value that is small enough for the VPN that
you are using. When in doubt, try 1280 and when worried about small performance differences increase
it until it again fails.

Tried that too, didn’t work either. I’m starting to think that its more of a routing problem. If it would be the mtu then I think I wouldn’t see the tcp traffic flowing into the interface thats connected to the Watchguard and coming out of the Watchguard.

Just to be clear the traffic traverses the network from VPN client to VPN server to watchguard just fine, it even comes back into the Watchguard connected interface but is then not forwarded to the VPN (sstp) client interface. Thats why I belive that something must be amiss with the VPN Server configuration but I can’t find anything.

bump.

The problem is probably not inside the MikroTik but in one of your other devices or networks.
You will need to debug this yourself as this is too specific to know what is happening from the outside.

That’s not very helpful. Since every attempt to establish a connection fail at the VPN Server the problem has to be there. Someone here has to have had a similar experience with a similar setup its not that exotic. I’m just routing traffic out a specific interface and don’t get it routed back. I tried playing with routes but none will take, tried some mangle rules didn’t help. Could it be a nat problem?

As I said, you’ll need to diagnose it yourself.
Use the packet sniffer tool to look at the network traffic at the different interfaces and see where it fails and why.

We’ll did a packet capture, which as I expected didn’t tell me anything new. The traffic comes in one interface and doesn’t go out the other. … I don’t get it … this is a real bummer.

Is there another way to implement a network where traffic from a VPN client is forwarded through the VPN Server to another device that does packet filtering?