Hello,
I’m having a problem with a Peplink with a VLAN configured with a DHCP relay.
Here’s the situation:
- My Guest WiFi network is 10.60.1.0/24, and the Peplink (10.60.1.1) is supposed to relay DHCP requests to a server located at a service provider via an IPsec tunnel (tunnel bearer: a firewall itself gateway/WAN link of the Peplink).
- The Peplink has IP 10.200.1.2 on its WAN interface and forwards packets to the firewall (10.200.1.1), the Peplink is configured for IP Forwading and not NAT
- The firewall knows the route to the 10.60.1.0/24 network, and the provider is ready to respond to DHCP requests via the tunnel.
Problem :
The Peplink changes the source IP of relayed Discover DHCP packets. Instead of keeping the original source IP (10.60.1.1), it replaces this IP with its WAN address (10.200.1.2).
This prevents the firewall from recognizing that these packets come from the 10.60.1.0/24 network and redirecting them via the IPsec tunnel.
Expectations:
I’m looking for a solution to disable this NAT behavior or configure the Peplink so that it retains the original source IP of relayed DHCP packets.
Thank you in advance for your help.
Sincerely,
Hi, @olivier.gaudet
I just thinking about what you describing.
So… at wan, you are using ip forward.
Peplink wan 10.200.1.2 and firewall is 10.200.1.1
and also… you have a ipsec between the peplink and the firewall… and not using nat.
Correct?
and you have a " route back " at firewall… this give the path to ping any ip host at network 10.60.1.0/24, behind the wan ip of peplink 10.200.1.2.
Please… ignore the tcp/ip address of my pictures…
1 Like
I looked at the DHCPrelay protocol, and how the peplink is behaving is valid. It is not the source IP of the DHCP unicast packet that is used to map the request to a subnet, but the Relay Agent IP embedded in the DHCP discover packet. That should be the LAN interface IP of the peplink.
Do you want to grab a packet capture of the relayed traffic and we can look into the actual packet.
I will check some of my DHCP relay traffic tomorrow to confirm this, but normally on Cisco and Juniper routers these sort of service packets are sent from a designated management loopback for consistency,
I don’t see a configuration parameter for Peplink to assign one of the interfaces to be the “admin” interface.
1 Like
Bonjour @MarceloBarros, 
So… at wan, you are using ip forward.
Yes, my peplink forwards its packets to its gateway (the firewall), which has a return route via OSPF.
Peplink wan 10.200.1.2 and firewall is 10.200.1.1
and also… you have a ipsec between the peplink and the firewall… and not using nat.
Yes for the first quote, but the IPSec tunnel with the remote site is carried by the firewall, which declares one of the Peplink’s VLANs (10.1.60.0/24) as the local network and 0.0.0.0/0 as the remote network, so all packets from the VLAN in question are redirected through the tunnel.
There is no tunnel between the peplink and the firewall, which are directly connected.
Hi…
Are you using a ospf between two direct connect devices?
Maybe can you just add a static route to solve this?
1 Like
Bonjour @Paul_Mossip,
I agree with you in principle that the interface that should relay the DHCP Discover should be the interface that received it in the first place, in my case 10.1.60.1.
Unfortunately this is not what happens, and the packet is relayed with address translation to 10.200.1.1 WAN IP of the Peplink, even though the WAN interface is configured for IP Forwarding.
I’ve attached a screenshot of the Wireshark trace.
LAN Side, I receive the multicast with Tag 60 of my VLAN 10.1.60.0/24 :
WAN Side, the packet is translated and takes the IP of the WAN interface, the firewall does its job and doesn’t send the packet through the tunnel :
OSPF is mandatory in my architecture for routing needs between several Peplink connected to the firewall.
However, I tested the option of a static route, but it doesn’t work because on Peplink you can’t make a static route to a destination outside the LAN.
I tried making an “Outbound Policy” which says that all traffic to [DHCP server IP] must exit via the WAN connected to the Peplink… same result.
I’m beginning to think that’s just not possible.
There’s still the idea of this checkbox, but I don’t know what it does exactly:
Hi…
the text, say… will keep the lan ip address… but my understand about this is … lan ip address of peplink… not from lan devices at lan side of peplink.
agree…
This is not an NAT issue… the peplink is sourcing the DHCP relay information from the interface towards the DHCP server. So it starts out as 10.200.1.2, and never changes. No amount of routing policy will change that packet.
On a cisco or juniper you would be able to specify “source-interface ge-1/1/1.0” for each type of application traffic.
That check box will source the traffic from the untagged VLan… Is that acceptable? Or you can just permit the DHCP relay traffic through the firewall.
2 Likes
I therefore understand that it is not possible to ensure that the packet retains the IP of the VLAN interface by relaying the DHCP request.
I’ll do it another way, by having the IPsec ported directly by the Peplink.
Thank you both for your time.
This topic caught my eye, because we’re having issues with NAT also when “IP forwarding” is chosen on the FusionHub device. Very weird issue, which I am trying to resolve with Peplink support.
When “NAT” is chosen on the FusionHub, DNS works fine. We send DNS requests dynamically with the DNS Proxy feature. When the SpeedFusion VPN is connected, on-site DNS servers are polled from the MBX. Clients receive the MBX as their DNS server in DHCP responses and receive responses appropriately for private and public DNS hosts.
When “IP Forwarding” is chosen on the FusionHub, DNS breaks for clients on the MBX. What we’ve seen with packet captures, and logs in the Fortigate firewall, is that the MBX device sends over the DNS requests over the SpeedFusion VPN, which was actually destined to itself (the MBX), without changing the source and destination. The Fortigate firewall refuses the packet and DNS times out for the client.
We’re on software version 8.5.1 on all devices.
Hi…
Your FusionHub… are also up to date?
Model: Peplink FusionHub
Firmware: 8.5.1s045 build 5258
and at FusionHub… are you using
IP Forwarding
uncheck box for Apply NAT on Remote peers
outgoing Internet traffic Remote peer(s) may route their outgoing Internet traffic to this unit. When this checkbox is checked their traffic will be NAT’d before forwarding out of this WAN. Leave this checkbox checked if you are not sure.
1 Like
Yes, the FusionHub is at version 8.5.1.
Here is the configuration on the FusionHub, on the Network → WAN page.
Hi…
WireShark sample file? Can be shared? Just a ping / dns request?
