Hairpin NAT - HTTPS WAN IP from LAN - Balance one is giving wrong SSL certificate (captive-portal.peplink.com)

Product Discussion Peplink Balance
3

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

3 Likes
4

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
5

I tried this :

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

But no change in behavior.

6

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

7

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
8

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?

9

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! ;<) ;:<)

10

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…

11

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?

2 Likes
12

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

1 Like
13

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.

14

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

1 Like
15

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.

16

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

1 Like
17

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 (192.168.100.1) 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.
18

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.

19

FYI, I submitted ticket #9100453 to track this.

20

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

1 Like
21

Thanks to Ron who helped solve the issue. This turned out to mostly be user error - I had neglected to forward port 443 on one of my servers for the main WAN IP, so naturally that was failing.

What was confusing is that in this case (LAN device tries to access WAN using main IP on port 443, with no other Inbound Access set for that port) the Peplink will answer the query, and deliver a 404 Not Found page, using the captive portal certificate.

I had turned off WAN administrative access (System / Admin Security / Web Admin Access: LAN only) and so this was unexpected behavior and led to confusion.

I’m not sure if that behavior is a “bug” per se, or just “undefined behavior”.

Some ideas:

  • Perhaps in this case rather than a 404 error, the connection should just fail outright?
  • The default SSL certificate used for the adminstrative access is called “captive-portal.peplink.com” which was confusing me (because I was not using the captive portal at all). Maybe the certificate should be named differently, or use a different cert for the admin access?
3 Likes
22

Thanks for this information. It is useful