DHCP response to source address not helper address

[Jason Brandt]

I ended up being able to handle this through iptables, unfortunately it
took a while to realize that UDP traffic wouldn't be converted by a
"catchall" rule.  Adding the following rule took care of the issue:

*iptables -t nat -A OUTPUT -p udp -d <dhcp-relay-private> -j DNAT
--to-destination <dhcp-relay-public-nat>  *

This requires a 1 to 1 nat on the router connected to the private network
(which handles NAT).


On Thu, Jun 27, 2013 at 9:06 AM, Jason Brandt <jbrandt at fsmail.bradley.edu>wrote:

> Yes, that matches what we were looking at doing.
>
>
> On Thu, Jun 27, 2013 at 2:57 AM, Steven Carr <sjcarr at gmail.com> wrote:
>
>> On 26 June 2013 22:56, Steven Carr <sjcarr at gmail.com> wrote:
>> > To get this to work you need a NAT gateway/firewall that has
>> > the ability to modify/manipulate/translate the packets so that they
>> > make sense on either side of the gateway (not sure which vendors have
>> > this capability for DHCP)
>>
>> Just to correct myself (shower epiphany moment this morning) this will
>> only be possible where you have a 1-to-1 NAT mapping and not a
>> 1-to-many, and in that scenario you would configure the DHCP server
>> with the external subnet and the gateway/firewall would re-write the
>> external address in the packet to the internal address on the other
>> side of the NAT boundary.
>>
>> Steve
>> _______________________________________________
>> dhcp-users mailing list
>> dhcp-users at lists.isc.org
>> https://lists.isc.org/mailman/listinfo/dhcp-users
>>
>
>
>
> --
> Jason K. Brandt
> Systems Administrator
> Bradley University
> (309) 677-2958
>



-- 
Jason K. Brandt
Systems Administrator
Bradley University
(309) 677-2958
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/dhcp-users/attachments/20130628/7ba534cb/attachment-0001.html>