Thread Info
  • State Verified Answer
  • Locked Locked
  • Replies 7 replies
  • Subscribers 2 subscribers
  • Views 8305 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

S2S IPsec problem

panicos

Hello guys,

 

I have a Sophos UTM 9.509-3 home edition and i have configured a S2S ipsec with a pocket router TP-LINK MR3020. Tunnel is UP (appears on both devices), but the traffic is somewhere being dropped.Please check files uploaded for Sophos configuration

 

Yes, i have firewall rules. even if i tick "automatic firewall rules" it is the same thing.

Local encryption domain Sophos:10.2.2.0/24

Remote encr domain TP Link:192.168.1.0/24

Sophos has dynamic public IP with dynamic DNS

TP LINK has dynamic public IP (from a 3G stick) with no dynamic DNS.

 

Phase 1 and 2 were manually created on both devices and they match. 

TP LINK: no firewall rules on it, no filtering of any kind, all is default.

Sophos: IPS logs show nothing strange, IPSEC logs, again nothing strange and also firewall rules show the traffic being allowed.

Sophos routing table:

ng_fw:/home/login # netstat -rn
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
1.1.1.0 0.0.0.0 255.255.255.0 U 0 0 0 tun0 ----> that is just a ssl vpn that i have configured and working OK
10.0.0.1 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0
10.1.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
10.2.2.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1.2
10.3.3.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1.3
127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 ppp0 -----> this is the local encryption domain of the TP LINK
ng_fw:/home/login #

Also, on the Sophos, a tcpdump shows that traffic from 192.168.1.0 comes through the tunnel, but i don't know how to check if it is properly routed back to the TPLINK:

ng_fw:/home/login # tcpdump -v -nni eth1.2 host 10.2.2.2 and host 192.168.1.102
tcpdump: listening on eth1.2, link-type EN10MB (Ethernet), capture size 65535 bytes
01:13:09.607980 IP (tos 0x0, ttl 126, id 14180, offset 0, flags [none], proto ICMP (1), length 60)
192.168.1.102 > 10.2.2.2: ICMP echo request, id 1, seq 411, length 40
01:13:09.608202 IP (tos 0x0, ttl 128, id 16122, offset 0, flags [none], proto ICMP (1), length 60)
10.2.2.2 > 192.168.1.102: ICMP echo reply, id 1, seq 411, length 40
01:13:14.090005 IP (tos 0x0, ttl 126, id 14187, offset 0, flags [none], proto ICMP (1), length 60)
192.168.1.102 > 10.2.2.2: ICMP echo request, id 1, seq 412, length 40
01:13:14.090298 IP (tos 0x0, ttl 128, id 16123, offset 0, flags [none], proto ICMP (1), length 60)
10.2.2.2 > 192.168.1.102: ICMP echo reply, id 1, seq 412, length 40

Other firewalls like Checkpoint or Fortigate have some means through which you can verify the exact path of traffic (like diag debug flow filter on Forti), but i don't know how to do it on Sophos.

Not only the icmp traffic is blocked, but any other traffic as well, so that is why my thought is it may be related to some routing issues .

 

Any ideeas, suggestions would be very helpfull.

 

Thanks
 



This thread was automatically locked due to age.
  • 0

    Hi,

    You can find the REF_ of the tunnel with:

    cc get_object_by_name ipsec_connection site_to_site 'VPN_MASINA'|grep \'ref\'

    That should give you a result like  'ref' => 'REF_IpsSitVpn_Masina',

    You can then watch the traffic inside the tunnel with:

    espdump -n --conn REF_IpsSitVpn_Masina -vv

    Does that give you any better clues?

    Check that anti-replay is activated in the TPLINK and that both sides have the same selections for NAT-T and DPD.

    Cheers - Bob

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • 0 in reply to BAlfson

    #BAlfson 

    could not find NAT-T and anti-reply options on the Tplink. DPD however is present and activated on both devices. An emulator with TPlink's GUI:

    https://www.tp-link.com/resources/simulator/MR3020_V3-2-23/index.htm

     

    Regarding the commands, it appears i don't have a tunnel interface?

    ng_fw:/home/login # cc get_object_by_name ipsec_connection site_to_site 'VPN_MASINA'|grep \'ref\'
    'ref' => 'REF_IpsSitVpnmasina',
    ng_fw:/home/login #
    ng_fw:/home/login # espdump -n --conn REF_IpsSitVpn_Masina
    ERROR: no tunnel found for 'REF_IpsSitVpn_Masina'
    ng_fw:/home/login #

  • 0 in reply to panicos

    We always only see what we know we're looking at! ;-)

    Instead of REF_IpsSitVpn_Masina, use REF_IpsSitVpnmasina.

    Cheers - Bob

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • 0 in reply to BAlfson

    Thank you Bob,

    i see indeed traffic inside the tunnel; pinging 192.168.1.101 towards 10.2.2.2 shows requests and reply inside the tunnel itself:

    ng_fw:/home/login # espdump -n --conn REF_IpsSitVpnmasina
    Running: tcpdump -ippp0 -Efile /tmp/espdump.16073/sas -s0 -n (esp) and ((host 5.12.233.166 and host 82.137.10.69))
    tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
    listening on ppp0, link-type LINUX_SLL (Linux cooked), capture size 65535 bytes
    08:04:30.153358 IP 82.137.10.69 > 5.12.233.166: ESP(spi=0x06a0c623,seq=0x24), length 132: IP 192.168.1.101 > 10.2.2.2: ICMP echo request, id 49076, seq 0, length 64 (ipip-proto-4)
    08:04:30.153863 IP 5.12.233.166 > 82.137.10.69: ESP(spi=0x04725ab1,seq=0x24), length 132: IP 10.2.2.2 > 192.168.1.101: ICMP echo reply, id 49076, seq 0, length 64 (ipip-proto-4)
    08:04:33.391409 IP 82.137.10.69 > 5.12.233.166: ESP(spi=0x06a0c623,seq=0x25), length 132: IP 192.168.1.101 > 10.2.2.2: ICMP echo request, id 49076, seq 1, length 64 (ipip-proto-4)
    08:04:33.391975 IP 5.12.233.166 > 82.137.10.69: ESP(spi=0x04725ab1,seq=0x25), length 132: IP 10.2.2.2 > 192.168.1.101: ICMP echo reply, id 49076, seq 1, length 64 (ipip-proto-4)

    So this means the TPlink is somehow blocking the returning traffic, but i have no ideea why and how.

  • +1 in reply to panicos

    I agree that it's the TPlink or something behind it.

    Cheers - Bob

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • 0 in reply to BAlfson

    I managed to resolve the issue with TPlink support. They provided my a new firmware in which they have added a NAT-T option. I enabled it on the TP link and now traffic is flowing as it should.

    Thanks everyone here for support.

    This thread may be closed.

Unfiltered HTML