Hello all, I'm trying to work on a setup using 2 x CHRs at separate locations, with an EoIP tunnel between them. The tunnel itself works, and I am able to route across it. At the A-side is a workstation (192.168.0.1) with a Sophos router as the default gateway (192.168.0.254) and the A-side CHR is the tunnel gateway (192.168.0.253). At the Z-side, there is the single CHR (172.16.100.254) which is acting as the default gateway and a Windows server (172.16.100.1) behind it. I have BGP configured between the two sites over the tunnel and this works as expected. Sessions are up and routes have propagated. 192.168.0.1 is able to ping and can traceroute to 172.16.100.1 and results are returned however, 172.16.100.1 cannot ping/traceroute to 192.168.0.1 which has me puzzled. I did some more digging, and the traceroute to 192.168.0.1 shows that the last hop before timeout is 192.168.0.253. I apologise for my poor explanation; however I hope it makes sense to someone. Would anyone be able to shed some light on why it may be doing this, or what I am missing? Thanks, CH
Given you can get one way, it’ll be a firewall issue. I reckon your are being “Sophos’d” and it’s simply blocking inbound ICMP.
On 3 Feb 2022, at 5:32 pm, Christopher Hawker <chris@thesysadmin.dev> wrote:
Hello all,
I'm trying to work on a setup using 2 x CHRs at separate locations, with an EoIP tunnel between them. The tunnel itself works, and I am able to route across it.
At the A-side is a workstation (192.168.0.1) with a Sophos router as the default gateway (192.168.0.254) and the A-side CHR is the tunnel gateway (192.168.0.253). At the Z-side, there is the single CHR (172.16.100.254) which is acting as the default gateway and a Windows server (172.16.100.1) behind it. I have BGP configured between the two sites over the tunnel and this works as expected. Sessions are up and routes have propagated.
192.168.0.1 is able to ping and can traceroute to 172.16.100.1 and results are returned however, 172.16.100.1 cannot ping/traceroute to 192.168.0.1 which has me puzzled. I did some more digging, and the traceroute to 192.168.0.1 shows that the last hop before timeout is 192.168.0.253.
I apologise for my poor explanation; however I hope it makes sense to someone. Would anyone be able to shed some light on why it may be doing this, or what I am missing?
Thanks, CH _______________________________________________ Public mailing list Public@talk.mikrotik.com.au http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com.au
Hi Dave, That was my thought too, however I've placed a rule at the top #1 that allows ICMP from any IP on any zone to reach any other IP on any other zone, same result. ________________________________ From: Public <public-bounces@talk.mikrotik.com.au> on behalf of Dave Browning <dave@dlbnetworks.com> Sent: Thursday, February 3, 2022 6:39 PM To: MikroTik Australia Public List <public@talk.mikrotik.com.au> Subject: Re: [MT-AU Public] Network Routing Issues Given you can get one way, it’ll be a firewall issue. I reckon your are being “Sophos’d” and it’s simply blocking inbound ICMP.
On 3 Feb 2022, at 5:32 pm, Christopher Hawker <chris@thesysadmin.dev> wrote:
Hello all,
I'm trying to work on a setup using 2 x CHRs at separate locations, with an EoIP tunnel between them. The tunnel itself works, and I am able to route across it.
At the A-side is a workstation (192.168.0.1) with a Sophos router as the default gateway (192.168.0.254) and the A-side CHR is the tunnel gateway (192.168.0.253). At the Z-side, there is the single CHR (172.16.100.254) which is acting as the default gateway and a Windows server (172.16.100.1) behind it. I have BGP configured between the two sites over the tunnel and this works as expected. Sessions are up and routes have propagated.
192.168.0.1 is able to ping and can traceroute to 172.16.100.1 and results are returned however, 172.16.100.1 cannot ping/traceroute to 192.168.0.1 which has me puzzled. I did some more digging, and the traceroute to 192.168.0.1 shows that the last hop before timeout is 192.168.0.253.
I apologise for my poor explanation; however I hope it makes sense to someone. Would anyone be able to shed some light on why it may be doing this, or what I am missing?
Thanks, CH _______________________________________________ Public mailing list Public@talk.mikrotik.com.au http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com.au
_______________________________________________ Public mailing list Public@talk.mikrotik.com.au http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com.au
On Thu, 2022-02-03 at 07:31 +0000, Christopher Hawker wrote:
192.168.0.1 is able to ping and can traceroute to 172.16.100.1 and results are returned however, 172.16.100.1 cannot ping/traceroute to 192.168.0.1 which has me puzzled.
Try something other than ping. Explicitly allow it at both ends and see how you go. Ping is very vulnerable. Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer@nullarbor.com.au) work +61 2 64957435 http://www.nullarbor.com.au mobile +61 428 957160 GPG fingerprint: 9FB6 C08F 91CB 5093 30EF 3E2F 8C94 EEBD 117C 4A10 Old fingerprint: CF68 0C56 EEE4 CC19 28D4 03B3 BCE0 E800 E31F 7254
participants (3)
-
Christopher Hawker -
Dave Browning -
Karl Auer