Routing between connected subnets - ICMP but not TCP

aesmith · Tue Sep 29, 2020 2:10 pm

Hi,
I have configured routing between two subnets which I'll call "Office" and "Home". Home is defined on the bridge and includes ether2, ether3, ether4 and the wireless. Office is connected to ether1.

From a host on Office subnet I can ping one particular device on the Home subnet, but can't open a TCP connection. Packet captures show the initial SYN being received on ether1 but not being sent on the bridge interface. It seems to apply to this host only. I don't have a problem for example opening a web page from our PVR that's connected via the same interface.

I'm not sure where I should be looking. The "problem" host is my SIP system and is regularly refreshing it's registrations. Could those connections in some way be interfering with forwarding TCP? It doesn't seem likely on the face of it as the SIP connections are going out of ether5.

Firewall shouldn't be interfering as the relevant interfaces are all in the same group "LAN"

/ip firewall filter
add action=accept chain=forward disabled=yes in-interface-list=LAN out-interface-list=LAN \
    src-address-list=""
add action=accept chain=input comment="defconf: accept established,related,untracked" \
    connection-state=established,related,untracked
add action=drop chain=input comment="defconf: drop invalid" connection-state=invalid
add action=accept chain=input comment="defconf: accept ICMP" protocol=icmp
add action=accept chain=input comment="defconf: accept to local loopback (for CAPsMAN)" \
    dst-address=127.0.0.1
add action=drop chain=input comment="defconf: drop all not coming from LAN" in-interface-list=\
    !LAN
add action=accept chain=forward comment="defconf: accept in ipsec policy" ipsec-policy=\
    in,ipsec
add action=accept chain=forward comment="defconf: accept out ipsec policy" ipsec-policy=\
    out,ipsec
add action=fasttrack-connection chain=forward comment="defconf: fasttrack" connection-state=\
    established,related
add action=accept chain=forward comment="defconf: accept established,related, untracked" \
    connection-state=established,related,untracked
add action=drop chain=forward comment="defconf: drop invalid" connection-state=invalid
add action=drop chain=forward comment="defconf: drop all from WAN not DSTNATed" \
    connection-nat-state=!dstnat connection-state=new in-interface-list=WAN
/ip firewall nat
add action=masquerade chain=srcnat comment="defconf: masquerade" ipsec-policy=out,none \
    out-interface-list=WAN

Thanks, Tony S

StubArea51 · Tue Sep 29, 2020 7:47 pm

The first thing i'd try is to disable all FW, NAT and MANGLE rules, even if you're sure they aren't interfering and test to see if TCP passes through to that host.

bpwl · Wed Sep 30, 2020 2:58 am

"Firewall shouldn't be interfering as the relevant interfaces are all in the same group "LAN" "

Very difficult, even impossible, to help if you only give part of the configuration.

One example: Above remark makes me wonder. ... all interfaces are in the LAN group .... if those interfaces are bridged together, what I guess is the case, only the fact if the bridge is in the LAN group matters.

aesmith · Wed Sep 30, 2020 10:50 am

Very difficult, even impossible, to help if you only give part of the configuration.

Fair comment. It's just that even with the "hide-sensitive" option export exposes a lot of stuff including SSIDs, SNMP communities and of course the full addressing scheme. It's possible to mask all this with a series of search and replace, but a bit fiddly.

Testing with all filter rules disabled the behaviour was unchanged, but I found I've been misunderstanding the Mikrotik capture.
Ingress ether1 is a routed port, with its own IP address. Capturing from that interface shows both transmit and receive traffic.
Egress ether3 which is a bridged port, the IP being applied to the bridge. Capturing from ether3 shows only receive and not transmit.

To see transmit I have to capture from bridge

I don't know what I did yesterday to capture what appeared to be ICMP being correctly transmitted, but not TCP. I have the pcap file and my notes say the capture was from "bridge" but if I repeat that today I see the TCP being transmitted with no reply, alongside the two way ICMP. And again today if I capture from ether3 I see only receive. I wish I'd taken a screenshot of capture settings to go with each capture file.

However the conclusion is that it must be a host problem, maybe it won't let you access the management page except from the local subnet.

aesmith · Thu Oct 01, 2020 10:33 am

Just to close this off, just for fun I created another NAT rule for access to just that one host from this source subnet, and with that in place it works. Confirming, I think that the Gigaset doesn't like admin access except from its connected subnet. It's not a lower level IP issue because it replies to ICMP ping.

Routing between connected subnets - ICMP but not TCP

Routing between connected subnets - ICMP but not TCP

Re: Routing between connected subnets - ICMP but not TCP

Re: Routing between connected subnets - ICMP but not TCP

Re: Routing between connected subnets - ICMP but not TCP

Re: Routing between connected subnets - ICMP but not TCP

Who is online