How to config NAT with a Public IP over VPN
Hope i am explaining this correctly.
Remote site : ( F500 company) gave me their correct peer IP and Encryption domain( network info).
Their public ip: 60.60.60.60 example.
their encryption domain: 200.200.200.x/24
My SITE B: ( has only one WAN IP on X1, and one internal network on X0)
my site public ip 70.70.70.70 example
my local network: 192.168.0.0/24
- They would not accept my 192.168.0.0/24 as encryption domain.
they said I need to configure my SITE: using NAT.
but they said i have to setup NAT in such a way that they can use my public IP as encryption domain. ( is this possible)
we have a sonicwall tz400,
So now i need to use nat policy(ies) so that all VPN data always goes thru the public ip-X1.
** I have read info on NAT over VPN to translate to a different subnet,
but for me : I have to configure my firewall so that for VPN they will configure to use the public ip both for peer IP and also for a encryption domain. Is this correct?
rest of the phase 1 and 2 IKE2 settings are already setup correctly from my side that they gave.
tunnel never has come up and also i get VPN remote timed out - the packets only send but no receive.
I am very confused. Please advise.
Answers
So you've read this?
It is quite common for companies to require VPN traffic be NATd. To answer the only identifiable questions I could find:
Yes it is possible to use a Public IP address as the encryption domain. I personally have never done it with a single public IP (always had blocks to use) but there shouldn't be any reason that you can't. If I had 1 public to work with I would NAT using the broadcast of the public subnet.
Thank you TKWITS for the reply and link.
I did go tru with the link you have sent, but i get messed up with the NAT policies.
assuming Site B is my side: example.
Please guide.
@Gustrastren,
This is how the NAT should look like:
Original source: 192.168.1.0/24
Translated source: 70.70.70.70
Original destination: Remote VPN network
Translated destination: Original
Original service: Any
Translated service: Original
Inbound interface: Any
Outbound Interface: Any
When creating the NAT manually, you should select 70.70.70.70 as the local network on the VPN policy.
If you have configured the VPN with the local network as 192.168.1.0/24, you can apply the NAT on the VPN policy directly on the 'Advanced' tab by enabling 'Apply NAT Policies' option.
You can then select, Translated Local Network as 70.70.70.70 and Translated Remote Network as Original.
Thanks!
Shipra Sahu
Technical Support Advisor, Premier Services
See the discussion here. https://community.sonicwall.com/technology-and-support/discussion/comment/7474
You'd replace the private IP address used in the example of that discussion with the public IP needed (e.g. 70.70.70.70).
Thank you @shiprasahu93 and @TKWITS
I did config as per the @shiprasahu93 explicit instructions and also double checked with @TKWITS 2nd reply link and advice.
I now get the following errors now. Not sure if something wrong in my side or remote, since i get no help from remote site.
IKEv2 Initiator: Send IKE_SA_INIT Request
IKEv2 Initiator: Received IKE_SA_INT response
IKEv2 Accept IKE SA Proposal
IKEv2 No NAT device detected between negotiating peers
IKEv2 Initiator: Send IKE_AUTH Request
Warning: IKEv2 Received notify error payload
IKEv2 Initiator: Negotiations failed. Extra payloads present.
Those are not errors. An error would say 'Error', not 'Warning'.
As I said in the other discussion:
Verify the Phase 1 and Phase 2 proposal configuration is correct on both sides of the tunnel (the settings are documented right?).
@TKWITS thank you
Also worried about the message:
Inform: IKEv2 No NAT device detected between negotiating peers
The forms with Phase 1 and 2 I checked it multiple times i have kept it the same as the one they gave me.
Only one thing in form, i ignored and do not have idea is: Supports Key Exchange for Subnets= NO
along with the errors the notes below ( if its any help)
IKEv2 Received notify error payload.
Notes: VPN Policy: from VPN1 to EOffice; No Proposal Chosen
IKEv2 Initiator: Negotiations failed. Extra payloads present.
Notes: VPN Policy: from VPN1 to EOffice; extra payloads present, failing negotiation.
Show us sanitized screenshots of your tunnel config and the forms. There's a mismatch (may not be on your end).
The message Inform: IKEv2 No NAT device detected between negotiating peers is normal and is a good thing. Think about what it is telling you instead of panicking.
If you expand log entries you should be able to see more details about why tunnels are failing to establish.
hello @TKWITS
thank you for helping me, below are screen shots, hope it helps to eliminate my configuration issue with no help from remote site.
ERROR:
Notes in above:
address objects below: (3 pic)
My public ip address object. ( I put lAN, that ok:?)
Remote Site B network address object. (pic#3)
NAT POLICIES BELOW (3 pics)
pic#1
pic#2
pic#3 below
VPN Base settings / policies ( total 5 pics)
pic#2
pic#3
pic#4 ( this matches exactly as form given)
pic#5
Since you are using a public IP address from your WAN interface, the address object representing that IP should be in the WAN zone. Start there.
The SA is established as evidenced by the log (generally regarded as phase 1 when using IKEv2), but after that it fails. Are you sure Phase 2 requires Perfect Forward Secrecy?
Try disabling Keep Alive and run a packet capture on the WAN interface looking at traffic to / from the remote site VPN gateway IP. Generate some traffic to force the tunnel to attempt establishment (ping should be enough), and see what you can gather from the capture.
Hello @TKWITS
as per your instructions:
Changed address obj. of public ip to WAN.
removed Prefetch F.S.
disabled Keepalives, No luck on tunnel coming up, on any of above changes.
below is packet capture info generated,
pinging into one of the remote VPN network IP-
still am not sure if issue is on my side.
for the dropped packet below is packe detail.
Ethernet Header
Ether Type: IP(0x800), Src=[f4:x:x:x:x:f4], Dst=[18:x:x:x:x:ec]
IP Packet Header
IP Type: ICMP(0x1), Src=[192.x.x.46], Dst=[208.x.x.20]
ICMP Packet Header
ICMP Type = 8(ECHO_REQUEST), ICMP Code = 0, ICMP Checksum = 5253
Value:[0]
DROPPED, Drop Code: 448(SA not found on lookup by SPI for outbound pkt), Module Id: 20(ipSec), (Ref.Id: _264_krugeQevgqpQwvrwv) 1:1)
You should be looking at the packet detail of the IKE negotiations on UDP 500, not at the dropped packet. We know why the packet was dropped (VPN tunnel not up).
It is entirely possible the configuration on the other end is incorrect. I've had to fight others that their config was the problem. Best thing to do is get a phone call going.