I am wondering what/if there is any configuration that enables arp replies.

I have an Ubuntu machine with two interfaces - one is ethernet to a non-public LAN, the other is Wifi which connects to the public internet. I need internet access on the private LAN for one computer temporarily, so I set an SNAT so that the address on the private LAN is mapped to the WiFi network LAN.

EDIT: I failed to mention that I also have a DNAT set to translate the address back.

Sending a ping outbounds to hits, but on return my WiFi router doesn't know "who has" this natted address ( so it sends an arp request.

I ran sudo arp -v -i wlp1s0 -s 84:7b:eb:35:a4:e0, where the hw addr is the hw addr associated with the ethernet link(I also ran the same command followed by 'pub' and it still didn't send). Here it is now in my arp table...:

Address                  HWtype  HWaddress           Flags Mask        Iface             ether   84:7b:eb:35:a4:e0   CM                    wlp1s0

However, the Ubuntu box still never replies to arps -

   19:26:59.542278 IP > google-public-dns-a.google.com: 19:27:51.477054 IP > ICMP echo request, id 3312, seq 2692, length 64
19:27:51.493773 ARP, Request who-has tell, length 46

The first message is the ping on the way to google, the second is the router looking for

Referencing this post, Linux does not reply to ARP request messages if requested IP address is associated with another (disabled) interface, I checked my kernel's Ip routing tables:

sudo ip route show table local
broadcast dev lo  proto kernel  scope link  src 
local dev lo  proto kernel  scope host  src 
local dev lo  proto kernel  scope host  src 
broadcast dev lo  proto kernel  scope link  src 
broadcast dev enp0s31f6  proto kernel  scope link  src 
local dev enp0s31f6  proto kernel  scope host  src 
broadcast dev enp0s31f6  proto kernel  scope link  src 
broadcast dev wlp1s0  proto kernel  scope link  src 
local dev wlp1s0  proto kernel  scope host  src 
broadcast dev wlp1s0  proto kernel  scope link  src 

In this question, the user had a route set for reaching the address(unlike my NAT), so I went ahead and added a route as well, and it still did not ARP:

route -n

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface         UG    600    0        0 wlp1s0     U     1000   0        0 wlp1s0   U     0      0        0 enp0s31f6   U     600    0        0 wlp1s0 UGH   0      0        0 enp0s31f6

Is there a setting on Ubuntu that I can change so that my machine will reply to ARP requests? If not, where is the next place to look to see why we're not responding?

EDIT 2: Here is how I set up the NAT:

sudo iptables -t nat -A POSTROUTING -s -j SNAT --to-source
sudo iptables -t nat -A PREROUTING -d -j DNAT --to-dest

EDIT 3: Changing to masquerading from DNAT/SNAT worked, and is far easier/more scalable.

  • 1
    The questions is not entirely clear. Does the router had an interface in that network? Is the machine able to ping the router? – Rui F Ribeiro Feb 23 at 7:53
  • 1
    @roaima: Sorry, that's wrong. You don't need corresponding DNAT rules for SNAT rules; the connection tracking does that automatically for you. Try it out if you don't believe me. – dirkt Feb 24 at 17:12
  • @RuiFRibeiro The router has an interface on the WiFi LAN, The Ubuntu machine can ping the router, and access the internet, etc.. – Ryan Feb 24 at 19:17
  • @roaima I have the corresponding DNAT set as well. – Ryan Feb 24 at 19:17
  • @dirkt i didn't have a machine handy to check, and TBH i can never remember if the check-in tracking handles an explicit snat/dnat rule out not. If that is the case i apologise. – roaima Feb 24 at 21:16

ARP replies are enabled automatically. It might be possible to turn them off with some entries in /proc or /sys, but I'd have to search for that.

What you have is a pretty standard situation for NAT. You haven't supplied the most important information, namely how you set up NAT, but usually one does it like this:

echo "1" > /proc/sys/net/ipv4/ip_forward

iptables -P INPUT ACCEPT
iptables -F INPUT
iptables -F OUTPUT 
iptables -P FORWARD DROP
iptables -F FORWARD 
iptables -t nat -F
iptables -A FORWARD -i $EXTIF -o $INTIF -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -i $INTIF -o $EXTIF -j ACCEPT
iptables -t nat -A POSTROUTING -o $EXTIF -j MASQUERADE

This enables forwarding, clears iptables rules, sets up a default policy, sets up filtering in the FORWARD chain so any packets going from $INTIF to $EXTIF are accepted, while for the reverse direction they must be tracked by the connection tracker (nf_conntrack). Finally all forwarded packets are MASQUERADED, which is SNAT with the address present on the interface, so even if this address changes, you'll always use the correct one. No extra routes needed. You can restrict forwarding by source address if you need to.

$INTIF is the internal interface (your LAN), $EXTIF is the external interface (your WLAN). You can make this persistent using whatever flavour of tools your Ubuntu uses (systemd etc.).

This works out of the box, no fiddling needed. The connection tracker will DNAT returning packets to the correct address with no need for an extra rule, forward them back to the LAN, and send out the ARP on the LAN interface, where it should get send out.

I suspect your setup is somehow different, which is why you end up with funny ARPs in the wrong place.

  • 1
    @roaima: Yes, but it's probably the solution to his problem, as far as I can guess from what he writes. See "XY problem". If you can tell him how to "enable ARP replies", go ahead and write an answer. – dirkt Feb 24 at 9:36
  • 1
    @roaima: I could have asked him how he set up NAT, read through it, and point out the mistakes. To avoid the additional round-trip, I just gave a working example. Note the "no extra routes needed", the "I added a route as well" might contribute to the behaviour he sees. – dirkt Feb 24 at 17:11
  • @dirkt I updated my answer to show how I have the NAT set up. Correct me if I am wrong, but the only difference between your masquerading scheme and my scheme is that MASQUERADE ing is dynamic. I think you are right, that is a better way to do it, but a static scheme should still work, and ARP replies should still be transmitted – Ryan Feb 24 at 19:32
  • 1
    Try removing the DNAT rule (and the extra route). You can debug this with tcpdump -ni wlp1s0 to test if the outgoing ping packet has correct source (the router's IP address on wlp1s0). Also verify with ip addr you are SNATing the correct address (or do you MASQUERADE), and you don't accidentally have multiple addresses assigned. – dirkt Feb 24 at 20:15
  • 1
    Then there was probably an IP address mixup somewhere, in theory it should also work with SNAT. – dirkt Feb 26 at 7:08

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.