Join the Conversation

To sign in, use your existing MySonicWall account. To create a free MySonicWall account click "Register".

Inbound IP on VPN shows public IP not subnet

Hi all.

I am new to this forum, to be honest didn't know it existed. My fault - sorry. Have an interesting issue, not sure if my mistake or just as designed and nothing can be done. (have also posted this before coming here, for transparency: https://community.spiceworks.com/topic/2267808-sonicwall-vpn-inbound-vpn-ip-shows-as-public-ip)

Our issue is that the site-to-site VPN we have to Azure shows the wrong source IP for traffic coming from Azure to on-prem. Instead of the sender host IP, the public IP od the Sonicwall interface is shown which breaks a lot of apps.

Basically our Azure is 172.168.1.x ---- > Public IP 185.85.x.x ------> Local 192.168.1.x

From local to Azure the source address shows as expected. But as mention from Azure to local the source appeards to be the Public IP. 

My config:



It is bound to Interface X1 which is our external interface (this is the IP that shows up for the inbound traffic).



Would appreciate if you could point me in the right direction.

Thank you!

Category: SSL VPN
Reply

Best Answer

Answers

  • [Deleted User][Deleted User] Cybersecurity Overlord ✭✭✭
    edited April 2020

    Hi @Odysseus2001 ,

    I just spoke with one of our experts @KaranM . Is your config set up according to this article? It may be you created the NAT and not the route. https://www.sonicwall.com/support/knowledge-base/how-can-i-configure-a-vpn-between-a-sonicwall-firewall-and-microsoft-azure/170505320011694/

    To clarify, where are you seeing "Shows the wrong source IP for traffic coming from Azure to on-prem."?

  • Thanks Chris.

    Will go through the article now. Thanks for pointing it out.

    I mean that if I look into wireshark the source IP of traffic to the on-prem host is the public IP, not the azure host local IP. Does it make sense?

    Basically we have an application which needs to register, the regisrar being hosted on prem. Because the host comes from a public Ip the controller rejects the communication.

    Regards,

    Dan

  • I have checked ever step in the article and the setup is exactly as the article says.


    The thing is the tunnel works fine but why does the traffic look like its coming from the public IP rather than the azure subnet IP's to hosts on local subnet.


    Thanks for your help! Appreciate it.

  • BWCBWC Cybersecurity Overlord ✭✭✭

    Hi @Odysseus2001

    if I see this correctly, the source-ip of the VPN traffic is your public IP and not the 172.168.x.y network from Azure, correct?

    Is there any NAT involved which could cause this? Did you enabled the packet-monitor on the SonicWall appliance and enabled the Advanced monitor filters to bring some light into this?

    --Michael@BWC

  • Odysseus2001Odysseus2001 Newbie ✭
    edited April 2020

    Hi Michael @BWC ,


    You are correct, that's our issue. I have enabled packet a packet trace (not prolific at doing these on sonicwall, maybe your guidance would be gold). I can see that ICMP traffic does indeed come from Public IP to the local 192.168.x.y network. I was pinging from a host 172.168.1.6

    I can share a diagnostic report with the config. The only NAT rules I can think are related in place are (can send you a full NAT table if you got a minute to look over)

    X0 - Is the local subnet (192.168.x.y)

    X1 - Public interface (185.x.x.x)

    Thanks again!

  • Odysseus, this is a textbook example of an issue which should be worked in a support case. The sensitive nature of the IP schemes you have shared are not worth the benefit of not paying for support if that is why you are pursuing it here. On the technical issue, it's likely there is a NAT Policy that is too general which is applying to the VPN. If you do have support, open a case and share the case # here and one of our experts like Karan or I can assist the case owner as needed.

  • I totally agree. Unfortunately we have just taken over this environment. The appliance is not well documented and we don't even know yet against which email it is registered.

    For the others and public. We have found the issue since and as you mention it was a NAT rule.

    The rule was setting the translated source from the Azure Vnet to the Public IP of the sonicwall. This was causing traffic to show as originating from public ip. Problem now is that we lost internet access on the Azure Vnet because of this.

    We have tunneled down all traffic to go through on-prem and out. But now I can;t find a way to route all traffic from Azure that is not destined to the local subnet to go out the WAN gateway. Any tips I would appreciate.


    Regards and thanks!

  • Thanks a lot @BWC for your help!

    It is finally working so we are happily in Azure now and everyone is happy :)

    Thanks!

Sign In or Register to comment.