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

Xg firewall trouble with vpn to another xg firewall on azure

Gretings i had a firewall on azure and a local firewall, i've stabilished the IPSEC VPN on from one to another, but it doesn't comunicate properly, i had the 10.1.2.0/24 on azure and a 192.168.10.0/24 and 192.168.0.0/24 on my local network, from azure machines i can ping on machines that are from the network 192.168.0.0/24 and the reverse does it so, but from azure i can ping from 10.1.2.0/24 to 192.168.10.0/24 but the inverse does not ocours, so basically we had 

192.168.0.0/24 <=> 10.1.2.0/24 OK!!!!

192.168.10.0/24 <=> 10.1.2.0/24 NOT OK!!!!

10.1.2.0/24 <=> 192.168.0.0/24 OK!!!!

10.1.2.0/24 <=> 192.168.10.0/24 OK!!!



This thread was automatically locked due to age.
Parents
  • Hello Joao,

    Thank you for contacting the Sophos Community!

    Are both of the Firewall XGs?

    Have you tried running a tcpdump on the XG to see if the Ping from 192.168.10.0/24 is going into ipsec0 and arriving to Azure?

    How does a  traceroute from 192.168.0.0 to 10.1.2.0/24 differs?

    Regards,


     
    Emmanuel (EmmoSophos)
    Technical Team Lead, Global Community Support
    Sophos Support VideosProduct Documentation  |  @SophosSupport  | Sign up for SMS Alerts
    If a post solves your question use the 'Verify Answer' link.
  • Hello, yes, i've done all the tcpdump but the trafic from 192.168.10.0/24 to 10.1.2.0/24 it's been sended to a wan port, specifically to the wan that we use to do the ipsec connection 

    and yes, it is a xg firewall on both sides

  • Hello Joao,

    Thank you for the follow-up!

    Is the SA for these two subnets in green color in the IPsec in the XGs?

    What is the output of the command below:

    # ip route get 10.1.2.x (x= a host IP of a device)

    Run the command from the XG that has the subnet 192.168.10.0/24

    Also the output of this command

    # ipsec statusall

    Regards,


     
    Emmanuel (EmmoSophos)
    Technical Team Lead, Global Community Support
    Sophos Support VideosProduct Documentation  |  @SophosSupport  | Sign up for SMS Alerts
    If a post solves your question use the 'Verify Answer' link.
  • XG135_XN03_SFOS 18.0.1 MR-1-Build396# ip route get 10.1.2.13
    10.1.2.13 dev ipsec0 table 220 src 192.168.0.100 uid 0
    cache

    it routes for the right ip but how do i test from the interface 192.168.10.100

  • Hello Joao,

    What was the output of the second command?

    Regards,


     
    Emmanuel (EmmoSophos)
    Technical Team Lead, Global Community Support
    Sophos Support VideosProduct Documentation  |  @SophosSupport  | Sign up for SMS Alerts
    If a post solves your question use the 'Verify Answer' link.
  • ipsec statusall
    Status of IKE charon daemon (strongSwan 5.5.3, Linux 4.14.38, x86_64):
    uptime: 5 hours, since Oct 21 10:27:45 2020
    malloc: sbrk 4861952, mmap 0, used 820784, free 4041168
    worker threads: 20 of 32 idle, 12/0/0/0 working, job queue: 0/0/0/0, scheduled: 10
    loaded plugins: charon aes des rc2 sha2 sha3 sha1 md5 random nonce x509 revocation constraints pubkey pkcs1 pkcs7 pkcs8 pkcs12 pgp dnskey sshkey pem openssl fips-prf curve25519 xcbc cmac hmac attr kernel-netlink socket-default stroke vici xauth-generic xauth-access-server ippool-access-server cop-updown garner-logging ha error-notify unity
    Listening IP addresses:
    169.254.234.5
    IP-EXT
    201.2.121.50
    201.2.121.52
    192.168.0.100
    IP-EXT
    192.168.10.100
    192.168.11.100
    192.168.48.1
    192.168.12.100
    192.168.223.1
    192.168.200.1
    172.16.2.1
    10.20.0.1
    10.0.11.1
    192.168.40.1
    192.168.30.1
    10.0.0.1
    192.168.100.1
    10.0.7.1
    10.0.9.1
    192.168.222.1
    10.10.0.1
    10.0.100.1
    10.85.234.5
    2001:db8::1:0
    Connections:
    CLIENTE_SERVIDOR_CLOUD_SERVIDOR-1: IP-EXT...IP-EXT IKEv2, dpddelay=30s
    CLIENTE_SERVIDOR_CLOUD_SERVIDOR-1: local: [10.0.200.10] uses pre-shared key authentication
    CLIENTE_SERVIDOR_CLOUD_SERVIDOR-1: remote: [10.0.0.96] uses pre-shared key authentication
    CLIENTE_SERVIDOR_CLOUD_SERVIDOR-1: child: 192.168.10.0/24 === 10.0.1.0/24 TUNNEL, dpdaction=restart
    EMPRESA-1: IP-EXT...201.216.71.14 IKEv2, dpddelay=10s
    EMPRESA-1: local: [10.173.192.1] uses pre-shared key authentication
    EMPRESA-1: remote: [10.192.173.1] uses pre-shared key authentication
    EMPRESA-1: child: 192.168.0.0/24 === 10.73.0.0/24 TUNNEL, dpdaction=clear
    EMPRESA_AZURE-1: IP-EXT...IP-AZURE IKEv2, dpddelay=30s
    EMPRESA_AZURE-1: local: [10.232.192.1] uses pre-shared key authentication
    EMPRESA_AZURE-1: remote: [10.232.192.1] uses pre-shared key authentication
    EMPRESA_AZURE-1: child: 192.168.0.0/16 === 10.1.2.0/22 TUNNEL, dpdaction=clear
    EMPRESA_AZURE-2: child: 192.168.0.0/16 === 10.0.128.4/32 TUNNEL, dpdaction=clear
    EMPRESA_AZURE-3: child: IP-EXT/32 === 10.1.2.0/22 TUNNEL, dpdaction=clear
    EMPRESA_AZURE-4: child: IP-EXT/32 === 10.0.128.4/32 TUNNEL, dpdaction=clear
    Security Associations (2 up, 1 connecting):
    EMPRESA_AZURE-1[11]: ESTABLISHED 31 minutes ago, IP-EXT[10.232.192.1]...IP-AZURE[10.232.192.1]
    EMPRESA_AZURE-1[11]: IKEv2 SPIs: 7a282d345353e88c_i 056815f2bd4e698d_r*, rekeying in 47 minutes
    EMPRESA_AZURE-1[11]: IKE proposal: AES_CBC_256/HMAC_SHA2_512_256/PRF_HMAC_SHA2_512/CURVE_25519
    EMPRESA_AZURE-1{4}: INSTALLED, TUNNEL, reqid 2, ESP in UDP SPIs: c4a2a720_i ccab105b_o
    EMPRESA_AZURE-1{4}: AES_CBC_256/HMAC_SHA2_512_256, 0 bytes_i, 0 bytes_o, rekeying in 16 minutes
    EMPRESA_AZURE-1{4}: 192.168.0.0/16 === 10.1.2.0/24
    EMPRESA_AZURE-3{5}: INSTALLED, TUNNEL, reqid 3, ESP in UDP SPIs: c6b9f8c5_i c50505fb_o
    EMPRESA_AZURE-3{5}: AES_CBC_256/HMAC_SHA2_512_256/CURVE_25519, 0 bytes_i, 0 bytes_o, rekeying in 20 minutes
    EMPRESA_AZURE-3{5}: IP-EXT/32 === 10.1.2.0/24
    EMPRESA_AZURE-2{6}: INSTALLED, TUNNEL, reqid 4, ESP in UDP SPIs: c6756033_i c93864fe_o
    EMPRESA_AZURE-2{6}: AES_CBC_256/HMAC_SHA2_512_256/CURVE_25519, 0 bytes_i, 0 bytes_o, rekeying in 18 minutes
    EMPRESA_AZURE-2{6}: 192.168.0.0/16 === 10.0.128.4/32
    EMPRESA_AZURE-4{7}: INSTALLED, TUNNEL, reqid 5, ESP in UDP SPIs: c68655ce_i c222ae45_o
    EMPRESA_AZURE-4{7}: AES_CBC_256/HMAC_SHA2_512_256/CURVE_25519, 0 bytes_i, 0 bytes_o, rekeying in 19 minutes
    EMPRESA_AZURE-4{7}: IP-EXT/32 === 10.0.128.4/32
    EMPRESA-1[6]: ESTABLISHED 41 minutes ago, IP-EXT[10.173.192.1]...201.216.71.14[10.192.173.1]
    EMPRESA-1[6]: IKEv2 SPIs: 47021fb18675d54a_i 2eee89eb3871faa6_r*, rekeying in 4 hours
    EMPRESA-1[6]: IKE proposal: 3DES_CBC/HMAC_MD5_96/PRF_HMAC_MD5/MODP_1536
    EMPRESA-1{3}: INSTALLED, TUNNEL, reqid 1, ESP SPIs: cf97227b_i cd07e6fc_o
    EMPRESA-1{3}: 3DES_CBC/HMAC_MD5_96/MODP_1536, 581521 bytes_i, 2005472 bytes_o (11201 pkts, 0s ago), rekeying in 4 hours
    EMPRESA-1{3}: 192.168.0.0/24 === 10.73.0.0/24
    CLIENTE_SERVIDOR_CLOUD_SERVIDOR-1[1]: CONNECTING, IP-EXT[%any]...IP-EXT[%any]
    CLIENTE_SERVIDOR_CLOUD_SERVIDOR-1[1]: IKEv2 SPIs: f163a3f618231c9c_i* 0000000000000000_r
    CLIENTE_SERVIDOR_CLOUD_SERVIDOR-1[1]: Tasks active: IKE_VENDOR IKE_INIT IKE_NATD IKE_CERT_PRE IKE_AUTH IKE_CERT_POST IKE_CONFIG CHILD_CREATE IKE_AUTH_LIFETIME

  • Hello Joao,

    As per this, I don't see a SA between 192.168.10.0/24 and 10.1.2.0/24.

    Could you please check in the XGs, that the subnet is entered correctly for 192.168.10.0/24 as well as for 192.168.0.0/24 in the IPSec tunnel configuration for Local and Remote Subnet accordingly.

    Regards,


     
    Emmanuel (EmmoSophos)
    Technical Team Lead, Global Community Support
    Sophos Support VideosProduct Documentation  |  @SophosSupport  | Sign up for SMS Alerts
    If a post solves your question use the 'Verify Answer' link.
Reply Children