[Help] L2TP Public IP – Nginx Proxy Manager Sees PPP Server IP Instead of Real Client IP

Hi everyone,

I'm currently using MikroTik RouterOS v7 with an L2TP/IPsec client connection to a VPN provider that assigns me a public IPv4 address.

The public IP works correctly for port forwarding (DST-NAT), and my Nginx Proxy Manager (NPM) is accessible from the internet.

However, I'm experiencing an issue where Nginx Proxy Manager always detects the L2TP server's PPP local IP instead of the actual public IP address of the connecting client.

1. Network Topology

Internet Client
(Real Public IP: x.x.x.x)
        |
        v
VPN Provider (Atlantic)
L2TP Server: 178.85.180.30
PPP Local IP: 178.85.180.192
        |
        | L2TP/IPsec Tunnel
        v
MikroTik RouterOS v7
PPP Remote / Assigned Public IP:
178.85.180.198
        |
        | DST-NAT
        v
Nginx Proxy Manager
192.168.252.129

2. Current Situation

My L2TP connection is established successfully with the following PPP addressing:

  • L2TP server endpoint: 178.85.180.30

  • PPP server local-address: 178.85.180.192

  • PPP client assigned address: 178.85.180.198

  • Internal NPM server: 192.168.252.129

I have configured DST-NAT to forward incoming HTTP/HTTPS requests from 178.85.180.198 to my internal Nginx Proxy Manager server.

The connection works, and websites hosted behind NPM are accessible from external networks.

However, the NPM access logs show:

GET https npm.xxxx.xxx "/api/"
[Client 178.85.180.192]
[Sent-to 192.168.252.129]
[HTTP 200]

Instead of showing the actual visitor's public IP, NPM always logs:

178.85.180.192

This is the PPP local-address on the VPN provider's L2TP server.

3. The Problem

Because all incoming connections appear to originate from 178.85.180.192, I cannot properly use the IP-based Access List (ACL) feature in Nginx Proxy Manager.

For example, I want to allow only specific public IP addresses or subnets to access certain proxy hosts, while denying everyone else.

Unfortunately, all visitors appear to have the same source IP.

4. Expected Behavior

I want the original client's source IP to be preserved throughout the connection:

Internet Client: x.x.x.x
        |
        v
L2TP VPN Provider
        |
        v
MikroTik DST-NAT
        |
        v
Nginx Proxy Manager

Detected Client IP: x.x.x.x

The public IP assigned through L2TP should continue to work for inbound port forwarding and outbound internet access.

5. Questions

  1. Is it normal for an L2TP server's PPP local-address to appear as the source IP for all forwarded incoming connections?

  2. Does PPP/L2TP itself modify the source IP, or would this indicate NAT somewhere along the forwarding path?

  3. Is there a way to preserve the original client IP when forwarding inbound connections through an L2TP tunnel?

  4. Could this issue be related to masquerade, SRC-NAT, connection tracking, or routing configuration on either MikroTik router?

  5. Would policy routing or connection marking help preserve the original source IP while ensuring return traffic goes back through the L2TP tunnel?

  6. What would be the recommended RouterOS v7 configuration for this scenario?

6. Additional Information

The VPN provider's PPP local and remote addresses are configured as described above. I understand that PPP address assignment itself should not automatically perform source NAT.

I have not yet confirmed through packet capture exactly where the source address changes.

I'm looking for a solution that preserves the original source IP without breaking existing DST-NAT functionality or outbound internet connectivity.

Any advice, configuration examples, or troubleshooting suggestions would be greatly appreciated.

Thank you!

NOTE : Endpoint/VPN Server is using CHR (Confirmed), client using Routerboard 7.25. Please help to give solution for provider vpn server and also to me

The whole AI analysis is useless (if it was useful, then AI would be sble to fix it for you). Rather you should show your actual full configuration (sensitive parts obfuscated). Relevant portion would be enough, but since we don't know where misconfiguration lies it'impossible to tell which part is relevant.

If I'd have to guess ... I'd say you have some SRC NAT configured which also works on "inbound" traffic ... but without seeing actual config that's impossible to say.