Hairpin NAT - HTTPS WAN IP from LAN - Balance one is giving wrong SSL certificate (

I have a peplink balance one, and I run some servers. The servers have DNS and valid SSL certificates. Accessing these from outside our network works fine.

But sometimes it fails. When I’m on a device inside the LAN, and I try to make an HTTPS access to an IP address that is one of our WAN IPs, my browser gives a “This connection is not private” message.

When I click into the details, I see that the reason is the SSL certificate is wrong - it’s actually the SSL certificate from the Balance one itself (

This shouldn’t be happening. I don’t even use the captive portal at all.

This has been happening for a long time, and was on both firmware 7 and firmware 8 series.

What can I do to diagnose / fix this?

More Details

  • Balance One running 8.0.0
  • two WANs
  • 4 static IPs set up on one WAN
  • 1 dynamic IP on the other WAN
  • Port Forwarding is set up to forward several IP/Port combinations to internal servers.
  • One VLAN is set up (but is not in use in this scenario)
  • The Balance One has DNS caching disabled


  • Requests to from outside our network: always works.
  • Requests to https://[WAN IP] from outside our network: always works (the right SSL certificate is delivered, but of course the browser complains since the IP doesn’t match the Certificate name)
  • Requests to from inside the network fails.
  • Requests to https://[WAN IP] from inside the network fails.
  • Requests to https://[LAN IP] from inside the network works (the right SSL certificate is delivered, but of course the browser complains since the IP doesn’t match the Certificate name)

What you need is NAT reflection which is also known as hairpinning (or NAT loopback). Peplink routers do not support this.


One way round this might be to use the 2nd WAN link. SO if your server IP is on WAN1, send all outbound traffic destined to that IP out of WAN2.

1 Like

I tried this :

Network / Outbound Policy: Source: Any Destiation: [WAN1 IP] Algorithm: Enforced: WAN2.

But no change in behavior.

Weird, this link Hairpin NAT suggests that Peplink routers do support hairpinning. Confused.

oh yeah! Well I haven’t tried it in ages or seen it working to date. Time to warm up the test lab and have go I think.

1 Like

Thanks for your help. I edited the title of this thread to include Hairpin NAT since it does feel like that specific issue.

More info:

  • outbound firewall rules: none
  • inbound firewall rules: none
  • inter VLAN routing is enabled.
  • internal firewall rules: several, but they are only set up to block most inter VLAN traffic (but allowing a few exceptions).

I don’t think these should be affecting NAT Hairpin, but maybe I’m exposing a bug?

This is going to be a “learning experience,” I think. Looking forward to hearing what you find out. “hairpinning” Hmmm. I must have spent too much time behind an oscilloscope and in bars! ;<) ;:<)

OK, that original thread (which dates to 2014) says something that I missed:

Once you have configured Inbound Access/Port Mappings/NAT Mappings rules, the internal clients can access the internal server using the public IP address.

So maybe I need to play with the NAT Mappings settings…

OK Confirmed. Hairpin NAT works a treat. Spun up a https web server on the LAN of a Balance One (8.0.0 build 4203) added port forwarding to it from public WAN IP I put on the WAN of the Balance and I could access it from internal devices using the WAN IP.

So yes. Port forwarding, firewall rules need inspection and are you using captive portal at all anywhere?


Do any of these block access to the internal web server IP?

1 Like

Interesting - can you conirm that you are using Inbound Access/Port Forwarding alone, but you did not set up anything using NAT Mapping ?

If so, this sounds like something else I have going on is causing trouble.

Yes this is all I used. Port forwarded from WAN IP to internal server IP.

1 Like

I have a VLAN and a LAN. Inter-VLAN routing is enabled because I wanted to allow a few devices to talk to each other, but I wanted most of it blocked so am using firewall rules.

My internal firewall rules look like this.

  1. Allow AppleTV (single IP on VLAN) to access everything on LAN
  2. Deny all IPs on VLAN to access all IPs on LAN
  3. Gaming Machine on LAN: allow to Peplink IP
  4. Gaming machine on LAN to Any: Deny
  5. Default: allow any from source to any.

Rule #4 was set up to allow a gaming machine to be on the LAN, but isolated from everyting else. Rule #3 was an attempt (perhaps futile?) to allow the gaming machine to talk to the Peplink to do NAT-PMP.

Update: I just disabled rules 1-4, applied the changes, and it did not fix the problem.

This is beginning to smell like it will need a ticket to be logged with engineering…

1 Like

Additional info: this only seems to happen when connecting to a server which is running on the main WAN IP.

If I connect to a server that has Inbound Port Mapping on one of the Additional Public IP Address then I don’t see this issue.

A few more tidbits:

I have a bunch of Outbound Policy settings:

  1. each server is set up to use a different WAN IP address - one is the main IP, and the other two are set to use Additional Public IP Address
  2. My two WANs are cable modems, and both of them have the same admin UI address ( and I have two rules set up so I can control which modem UI I’m accessing.
  3. HTTPS_Persistence is set from any source to any destination on 443.

Martin, in the past you suggested I just use NAT Mapping: NAT Mappings vs. Inbound / Outbound Policy for Additional Public IP Address

Maybe I should try that - although NAT Mapping is complicated, it might actually be simpler than my current setup which requires a combination of Port Forwarding, Outbound Policy, and Internal Firewall.

FYI, I submitted ticket #9100453 to track this.

Hairpin NAT should work without issues so we will follow up with the ticket.

1 Like