Linux respond with source address of a virtual interface

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP











up vote
0
down vote

favorite












Hoping this is the correct forum.



I have a Linux (Centos 7) server with Quagga (for BGP) and DNSMASQ (for DHCP) installed. We are running DHCP services over BGP for redundancy.



Currently, the client is reaching out to the DHCP server via BGP ip address (10.10.12.12) and sending a DISCOVER packet. The DHCP server sees it and makes an OFFER, however the OFFER is not getting back to the client because the DHCP server is sending it back with a source address of the internal IP of the DHCP server (172.18.25.10 - You can see proof of this below in second tcpdump packet) and not the BGP ip address (10.10.12.12). 172.18.25.10 is being blocked by our firewall (and we do not want to open it).



How might I set the source address returning back to the client as the BGP address instead of the internal IP? I've been playing around with ip routing configurations but can't seem to get it right. Any ideas?



Routes



$ ip r
default via 172.18.25.1 dev ens256 proto static metric 100
172.18.25.0/24 dev ens256 proto kernel scope link src 172.18.25.10 metric 100


Interfaces



$ ifconfig
ens256: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 172.18.25.10 netmask 255.255.255.0 broadcast 172.18.25.255
(truncated for brevity...)

lo:10: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 10.10.12.12 netmask 255.255.255.255
loop txqueuelen 1 (Local Loopback)


Virtual Interface config for lo:10



DEVICE=lo:10
IPADDR=10.10.12.12
NETMASK=255.255.255.255
ONBOOT=yes
NAME=lo10


DHCP server tcpdump



17:44:11.833026 IP (tos 0x0, ttl 62, id 4923, offset 0, flags [none], proto UDP (17), length 388)
192.168.69.1.67 > 10.10.12.12.67: [udp sum ok] BOOTP/DHCP, Request from a8:60:b6:0c:49:cd, length 360, hops 1, xid 0xad97213f, secs 8, Flags [none] (0x0000)
Gateway-IP 192.168.69.1
Client-Ethernet-Address a8:60:b6:0c:49:cd
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: Discover
Parameter-Request Option 55, length 10:
Subnet-Mask, Classless-Static-Route, Default-Gateway, Domain-Name-Server
Domain-Name, Option 119, Option 252, LDAP
Netbios-Name-Server, Netbios-Node
MSZ Option 57, length 2: 1500
Client-ID Option 61, length 7: ether a8:60:b6:0c:49:cd
Lease-Time Option 51, length 4: 7776000
Hostname Option 12, length 9: "tests-MBP"
Agent-Information Option 82, length 57:
Circuit-ID SubOption 1, length 42: ToR-vc.corp.fake01:ge-0/0/20.0:dhcp-test-69
Remote-ID SubOption 2, length 11: ge-0/0/20.0

17:44:11.833196 IP (tos 0xc0, ttl 64, id 4315, offset 0, flags [none], proto UDP (17), length 394)
172.18.25.10.67 > 192.168.69.1.67: [bad udp cksum 0xcc4d -> 0xe7d1!] BOOTP/DHCP, Reply, length 366, hops 1, xid 0xad97213f, secs 8, Flags [none] (0x0000)
Your-IP 192.168.69.230
Server-IP 172.18.25.10
Gateway-IP 192.168.69.1
Client-Ethernet-Address a8:60:b6:0c:49:cd
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: Offer
Server-ID Option 54, length 4: 172.18.25.10
Lease-Time Option 51, length 4: 300
RN Option 58, length 4: 150
RB Option 59, length 4: 262
Subnet-Mask Option 1, length 4: 255.255.255.0
BR Option 28, length 4: 192.168.69.255
Default-Gateway Option 3, length 4: 192.168.69.1
Domain-Name-Server Option 6, length 4: 172.18.25.10
Domain-Name Option 15, length 13: "example.com"
Agent-Information Option 82, length 57:
Circuit-ID SubOption 1, length 42: ToR-vc.corp.fake01:ge-0/0/20.0:dhcp-test-69
Remote-ID SubOption 2, length 11: ge-0/0/20.0






share|improve this question



















  • Not exactly necessarily related to your question, but is there a reason you're using a non-loopback address on a (virtual) loopback interface? Seeing a lo* interface with an address outside of 127.0.0.0/8 struck me as very odd indeed.
    – DopeGhoti
    Jun 6 at 21:58










  • see comments below
    – Devin
    Jun 6 at 22:57














up vote
0
down vote

favorite












Hoping this is the correct forum.



I have a Linux (Centos 7) server with Quagga (for BGP) and DNSMASQ (for DHCP) installed. We are running DHCP services over BGP for redundancy.



Currently, the client is reaching out to the DHCP server via BGP ip address (10.10.12.12) and sending a DISCOVER packet. The DHCP server sees it and makes an OFFER, however the OFFER is not getting back to the client because the DHCP server is sending it back with a source address of the internal IP of the DHCP server (172.18.25.10 - You can see proof of this below in second tcpdump packet) and not the BGP ip address (10.10.12.12). 172.18.25.10 is being blocked by our firewall (and we do not want to open it).



How might I set the source address returning back to the client as the BGP address instead of the internal IP? I've been playing around with ip routing configurations but can't seem to get it right. Any ideas?



Routes



$ ip r
default via 172.18.25.1 dev ens256 proto static metric 100
172.18.25.0/24 dev ens256 proto kernel scope link src 172.18.25.10 metric 100


Interfaces



$ ifconfig
ens256: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 172.18.25.10 netmask 255.255.255.0 broadcast 172.18.25.255
(truncated for brevity...)

lo:10: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 10.10.12.12 netmask 255.255.255.255
loop txqueuelen 1 (Local Loopback)


Virtual Interface config for lo:10



DEVICE=lo:10
IPADDR=10.10.12.12
NETMASK=255.255.255.255
ONBOOT=yes
NAME=lo10


DHCP server tcpdump



17:44:11.833026 IP (tos 0x0, ttl 62, id 4923, offset 0, flags [none], proto UDP (17), length 388)
192.168.69.1.67 > 10.10.12.12.67: [udp sum ok] BOOTP/DHCP, Request from a8:60:b6:0c:49:cd, length 360, hops 1, xid 0xad97213f, secs 8, Flags [none] (0x0000)
Gateway-IP 192.168.69.1
Client-Ethernet-Address a8:60:b6:0c:49:cd
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: Discover
Parameter-Request Option 55, length 10:
Subnet-Mask, Classless-Static-Route, Default-Gateway, Domain-Name-Server
Domain-Name, Option 119, Option 252, LDAP
Netbios-Name-Server, Netbios-Node
MSZ Option 57, length 2: 1500
Client-ID Option 61, length 7: ether a8:60:b6:0c:49:cd
Lease-Time Option 51, length 4: 7776000
Hostname Option 12, length 9: "tests-MBP"
Agent-Information Option 82, length 57:
Circuit-ID SubOption 1, length 42: ToR-vc.corp.fake01:ge-0/0/20.0:dhcp-test-69
Remote-ID SubOption 2, length 11: ge-0/0/20.0

17:44:11.833196 IP (tos 0xc0, ttl 64, id 4315, offset 0, flags [none], proto UDP (17), length 394)
172.18.25.10.67 > 192.168.69.1.67: [bad udp cksum 0xcc4d -> 0xe7d1!] BOOTP/DHCP, Reply, length 366, hops 1, xid 0xad97213f, secs 8, Flags [none] (0x0000)
Your-IP 192.168.69.230
Server-IP 172.18.25.10
Gateway-IP 192.168.69.1
Client-Ethernet-Address a8:60:b6:0c:49:cd
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: Offer
Server-ID Option 54, length 4: 172.18.25.10
Lease-Time Option 51, length 4: 300
RN Option 58, length 4: 150
RB Option 59, length 4: 262
Subnet-Mask Option 1, length 4: 255.255.255.0
BR Option 28, length 4: 192.168.69.255
Default-Gateway Option 3, length 4: 192.168.69.1
Domain-Name-Server Option 6, length 4: 172.18.25.10
Domain-Name Option 15, length 13: "example.com"
Agent-Information Option 82, length 57:
Circuit-ID SubOption 1, length 42: ToR-vc.corp.fake01:ge-0/0/20.0:dhcp-test-69
Remote-ID SubOption 2, length 11: ge-0/0/20.0






share|improve this question



















  • Not exactly necessarily related to your question, but is there a reason you're using a non-loopback address on a (virtual) loopback interface? Seeing a lo* interface with an address outside of 127.0.0.0/8 struck me as very odd indeed.
    – DopeGhoti
    Jun 6 at 21:58










  • see comments below
    – Devin
    Jun 6 at 22:57












up vote
0
down vote

favorite









up vote
0
down vote

favorite











Hoping this is the correct forum.



I have a Linux (Centos 7) server with Quagga (for BGP) and DNSMASQ (for DHCP) installed. We are running DHCP services over BGP for redundancy.



Currently, the client is reaching out to the DHCP server via BGP ip address (10.10.12.12) and sending a DISCOVER packet. The DHCP server sees it and makes an OFFER, however the OFFER is not getting back to the client because the DHCP server is sending it back with a source address of the internal IP of the DHCP server (172.18.25.10 - You can see proof of this below in second tcpdump packet) and not the BGP ip address (10.10.12.12). 172.18.25.10 is being blocked by our firewall (and we do not want to open it).



How might I set the source address returning back to the client as the BGP address instead of the internal IP? I've been playing around with ip routing configurations but can't seem to get it right. Any ideas?



Routes



$ ip r
default via 172.18.25.1 dev ens256 proto static metric 100
172.18.25.0/24 dev ens256 proto kernel scope link src 172.18.25.10 metric 100


Interfaces



$ ifconfig
ens256: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 172.18.25.10 netmask 255.255.255.0 broadcast 172.18.25.255
(truncated for brevity...)

lo:10: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 10.10.12.12 netmask 255.255.255.255
loop txqueuelen 1 (Local Loopback)


Virtual Interface config for lo:10



DEVICE=lo:10
IPADDR=10.10.12.12
NETMASK=255.255.255.255
ONBOOT=yes
NAME=lo10


DHCP server tcpdump



17:44:11.833026 IP (tos 0x0, ttl 62, id 4923, offset 0, flags [none], proto UDP (17), length 388)
192.168.69.1.67 > 10.10.12.12.67: [udp sum ok] BOOTP/DHCP, Request from a8:60:b6:0c:49:cd, length 360, hops 1, xid 0xad97213f, secs 8, Flags [none] (0x0000)
Gateway-IP 192.168.69.1
Client-Ethernet-Address a8:60:b6:0c:49:cd
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: Discover
Parameter-Request Option 55, length 10:
Subnet-Mask, Classless-Static-Route, Default-Gateway, Domain-Name-Server
Domain-Name, Option 119, Option 252, LDAP
Netbios-Name-Server, Netbios-Node
MSZ Option 57, length 2: 1500
Client-ID Option 61, length 7: ether a8:60:b6:0c:49:cd
Lease-Time Option 51, length 4: 7776000
Hostname Option 12, length 9: "tests-MBP"
Agent-Information Option 82, length 57:
Circuit-ID SubOption 1, length 42: ToR-vc.corp.fake01:ge-0/0/20.0:dhcp-test-69
Remote-ID SubOption 2, length 11: ge-0/0/20.0

17:44:11.833196 IP (tos 0xc0, ttl 64, id 4315, offset 0, flags [none], proto UDP (17), length 394)
172.18.25.10.67 > 192.168.69.1.67: [bad udp cksum 0xcc4d -> 0xe7d1!] BOOTP/DHCP, Reply, length 366, hops 1, xid 0xad97213f, secs 8, Flags [none] (0x0000)
Your-IP 192.168.69.230
Server-IP 172.18.25.10
Gateway-IP 192.168.69.1
Client-Ethernet-Address a8:60:b6:0c:49:cd
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: Offer
Server-ID Option 54, length 4: 172.18.25.10
Lease-Time Option 51, length 4: 300
RN Option 58, length 4: 150
RB Option 59, length 4: 262
Subnet-Mask Option 1, length 4: 255.255.255.0
BR Option 28, length 4: 192.168.69.255
Default-Gateway Option 3, length 4: 192.168.69.1
Domain-Name-Server Option 6, length 4: 172.18.25.10
Domain-Name Option 15, length 13: "example.com"
Agent-Information Option 82, length 57:
Circuit-ID SubOption 1, length 42: ToR-vc.corp.fake01:ge-0/0/20.0:dhcp-test-69
Remote-ID SubOption 2, length 11: ge-0/0/20.0






share|improve this question











Hoping this is the correct forum.



I have a Linux (Centos 7) server with Quagga (for BGP) and DNSMASQ (for DHCP) installed. We are running DHCP services over BGP for redundancy.



Currently, the client is reaching out to the DHCP server via BGP ip address (10.10.12.12) and sending a DISCOVER packet. The DHCP server sees it and makes an OFFER, however the OFFER is not getting back to the client because the DHCP server is sending it back with a source address of the internal IP of the DHCP server (172.18.25.10 - You can see proof of this below in second tcpdump packet) and not the BGP ip address (10.10.12.12). 172.18.25.10 is being blocked by our firewall (and we do not want to open it).



How might I set the source address returning back to the client as the BGP address instead of the internal IP? I've been playing around with ip routing configurations but can't seem to get it right. Any ideas?



Routes



$ ip r
default via 172.18.25.1 dev ens256 proto static metric 100
172.18.25.0/24 dev ens256 proto kernel scope link src 172.18.25.10 metric 100


Interfaces



$ ifconfig
ens256: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 172.18.25.10 netmask 255.255.255.0 broadcast 172.18.25.255
(truncated for brevity...)

lo:10: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 10.10.12.12 netmask 255.255.255.255
loop txqueuelen 1 (Local Loopback)


Virtual Interface config for lo:10



DEVICE=lo:10
IPADDR=10.10.12.12
NETMASK=255.255.255.255
ONBOOT=yes
NAME=lo10


DHCP server tcpdump



17:44:11.833026 IP (tos 0x0, ttl 62, id 4923, offset 0, flags [none], proto UDP (17), length 388)
192.168.69.1.67 > 10.10.12.12.67: [udp sum ok] BOOTP/DHCP, Request from a8:60:b6:0c:49:cd, length 360, hops 1, xid 0xad97213f, secs 8, Flags [none] (0x0000)
Gateway-IP 192.168.69.1
Client-Ethernet-Address a8:60:b6:0c:49:cd
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: Discover
Parameter-Request Option 55, length 10:
Subnet-Mask, Classless-Static-Route, Default-Gateway, Domain-Name-Server
Domain-Name, Option 119, Option 252, LDAP
Netbios-Name-Server, Netbios-Node
MSZ Option 57, length 2: 1500
Client-ID Option 61, length 7: ether a8:60:b6:0c:49:cd
Lease-Time Option 51, length 4: 7776000
Hostname Option 12, length 9: "tests-MBP"
Agent-Information Option 82, length 57:
Circuit-ID SubOption 1, length 42: ToR-vc.corp.fake01:ge-0/0/20.0:dhcp-test-69
Remote-ID SubOption 2, length 11: ge-0/0/20.0

17:44:11.833196 IP (tos 0xc0, ttl 64, id 4315, offset 0, flags [none], proto UDP (17), length 394)
172.18.25.10.67 > 192.168.69.1.67: [bad udp cksum 0xcc4d -> 0xe7d1!] BOOTP/DHCP, Reply, length 366, hops 1, xid 0xad97213f, secs 8, Flags [none] (0x0000)
Your-IP 192.168.69.230
Server-IP 172.18.25.10
Gateway-IP 192.168.69.1
Client-Ethernet-Address a8:60:b6:0c:49:cd
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: Offer
Server-ID Option 54, length 4: 172.18.25.10
Lease-Time Option 51, length 4: 300
RN Option 58, length 4: 150
RB Option 59, length 4: 262
Subnet-Mask Option 1, length 4: 255.255.255.0
BR Option 28, length 4: 192.168.69.255
Default-Gateway Option 3, length 4: 192.168.69.1
Domain-Name-Server Option 6, length 4: 172.18.25.10
Domain-Name Option 15, length 13: "example.com"
Agent-Information Option 82, length 57:
Circuit-ID SubOption 1, length 42: ToR-vc.corp.fake01:ge-0/0/20.0:dhcp-test-69
Remote-ID SubOption 2, length 11: ge-0/0/20.0








share|improve this question










share|improve this question




share|improve this question









asked Jun 6 at 21:51









Devin

1163




1163











  • Not exactly necessarily related to your question, but is there a reason you're using a non-loopback address on a (virtual) loopback interface? Seeing a lo* interface with an address outside of 127.0.0.0/8 struck me as very odd indeed.
    – DopeGhoti
    Jun 6 at 21:58










  • see comments below
    – Devin
    Jun 6 at 22:57
















  • Not exactly necessarily related to your question, but is there a reason you're using a non-loopback address on a (virtual) loopback interface? Seeing a lo* interface with an address outside of 127.0.0.0/8 struck me as very odd indeed.
    – DopeGhoti
    Jun 6 at 21:58










  • see comments below
    – Devin
    Jun 6 at 22:57















Not exactly necessarily related to your question, but is there a reason you're using a non-loopback address on a (virtual) loopback interface? Seeing a lo* interface with an address outside of 127.0.0.0/8 struck me as very odd indeed.
– DopeGhoti
Jun 6 at 21:58




Not exactly necessarily related to your question, but is there a reason you're using a non-loopback address on a (virtual) loopback interface? Seeing a lo* interface with an address outside of 127.0.0.0/8 struck me as very odd indeed.
– DopeGhoti
Jun 6 at 21:58












see comments below
– Devin
Jun 6 at 22:57




see comments below
– Devin
Jun 6 at 22:57










2 Answers
2






active

oldest

votes

















up vote
1
down vote













Based on iptables: change local source address if destination address matches I was able to find a solution with a simple ip route added.



ip route add 192.168.69.1/32 via 172.18.25.1 src 10.10.12.12


or



ip route add 0.0.0.0/0 via 172.18.25.1 src 10.10.12.12





share|improve this answer




























    up vote
    0
    down vote













    If I understand well this is a problem with dnsmasq, the software offer a few solutions to your problem:
    interface to force listening of a specified interface e.g:



    interface=lo:10


    no-dhcp-interface to disable the distribution of DHCP on this interface e.g:



    no-dhcp-interface=ens256


    listen-address, looking like interface but specifying a binding IP instead e.g:



    listen-address=10.10.12.12


    From the dnsmasq documentation :



    -i, --interface=<interface name> Listen only on the specified interface(s). 
    Dnsmasq automatically adds the loopback (local) interface to the list of
    interfaces to use when the --interface option is used. If no --interface or

    -2, --no-dhcp-interface=<interface name>
    Do not provide DHCP or TFTP on the specified interface, but do provide DNS
    service.

    -a, --listen-address=<ipaddr>
    Listen on the given IP address(es). Both --interface and --listen-address
    options may be given, in which case the set of both interfaces and addresses
    is used. Note that if no --interface option is given, but --listen-address
    is, dnsmasq will not automatically listen on the loopback interface. To
    achieve this, its IP address, 127.0.0.1, must be explicitly given as a --
    listen-address option.





    share|improve this answer





















    • Tried it. dnsmasq doesn't see the traffic at all. It seems to only pickup on the ens256 interface, there is no OFFER, only the DISCOVER. Regardless, not sure that would help resolve the issue of setting source address as the lo:10 interface address (10.10.12.12)
      – Devin
      Jun 6 at 22:21










    • Is it possible that trying to use the loopback interface for non-localhost traffic is part of the problem?
      – DopeGhoti
      Jun 6 at 22:25










    • Typically it's assigned to the loopback with BGP because a loopback interface always remains up and keeps BGP peering established as long as there is a link available to reach the peer.
      – Devin
      Jun 6 at 22:52










    Your Answer







    StackExchange.ready(function()
    var channelOptions =
    tags: "".split(" "),
    id: "106"
    ;
    initTagRenderer("".split(" "), "".split(" "), channelOptions);

    StackExchange.using("externalEditor", function()
    // Have to fire editor after snippets, if snippets enabled
    if (StackExchange.settings.snippets.snippetsEnabled)
    StackExchange.using("snippets", function()
    createEditor();
    );

    else
    createEditor();

    );

    function createEditor()
    StackExchange.prepareEditor(
    heartbeatType: 'answer',
    convertImagesToLinks: false,
    noModals: false,
    showLowRepImageUploadWarning: true,
    reputationToPostImages: null,
    bindNavPrevention: true,
    postfix: "",
    onDemand: true,
    discardSelector: ".discard-answer"
    ,immediatelyShowMarkdownHelp:true
    );



    );








     

    draft saved


    draft discarded


















    StackExchange.ready(
    function ()
    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f448296%2flinux-respond-with-source-address-of-a-virtual-interface%23new-answer', 'question_page');

    );

    Post as a guest






























    2 Answers
    2






    active

    oldest

    votes








    2 Answers
    2






    active

    oldest

    votes









    active

    oldest

    votes






    active

    oldest

    votes








    up vote
    1
    down vote













    Based on iptables: change local source address if destination address matches I was able to find a solution with a simple ip route added.



    ip route add 192.168.69.1/32 via 172.18.25.1 src 10.10.12.12


    or



    ip route add 0.0.0.0/0 via 172.18.25.1 src 10.10.12.12





    share|improve this answer

























      up vote
      1
      down vote













      Based on iptables: change local source address if destination address matches I was able to find a solution with a simple ip route added.



      ip route add 192.168.69.1/32 via 172.18.25.1 src 10.10.12.12


      or



      ip route add 0.0.0.0/0 via 172.18.25.1 src 10.10.12.12





      share|improve this answer























        up vote
        1
        down vote










        up vote
        1
        down vote









        Based on iptables: change local source address if destination address matches I was able to find a solution with a simple ip route added.



        ip route add 192.168.69.1/32 via 172.18.25.1 src 10.10.12.12


        or



        ip route add 0.0.0.0/0 via 172.18.25.1 src 10.10.12.12





        share|improve this answer













        Based on iptables: change local source address if destination address matches I was able to find a solution with a simple ip route added.



        ip route add 192.168.69.1/32 via 172.18.25.1 src 10.10.12.12


        or



        ip route add 0.0.0.0/0 via 172.18.25.1 src 10.10.12.12






        share|improve this answer













        share|improve this answer



        share|improve this answer











        answered Jun 6 at 23:43









        Devin

        1163




        1163






















            up vote
            0
            down vote













            If I understand well this is a problem with dnsmasq, the software offer a few solutions to your problem:
            interface to force listening of a specified interface e.g:



            interface=lo:10


            no-dhcp-interface to disable the distribution of DHCP on this interface e.g:



            no-dhcp-interface=ens256


            listen-address, looking like interface but specifying a binding IP instead e.g:



            listen-address=10.10.12.12


            From the dnsmasq documentation :



            -i, --interface=<interface name> Listen only on the specified interface(s). 
            Dnsmasq automatically adds the loopback (local) interface to the list of
            interfaces to use when the --interface option is used. If no --interface or

            -2, --no-dhcp-interface=<interface name>
            Do not provide DHCP or TFTP on the specified interface, but do provide DNS
            service.

            -a, --listen-address=<ipaddr>
            Listen on the given IP address(es). Both --interface and --listen-address
            options may be given, in which case the set of both interfaces and addresses
            is used. Note that if no --interface option is given, but --listen-address
            is, dnsmasq will not automatically listen on the loopback interface. To
            achieve this, its IP address, 127.0.0.1, must be explicitly given as a --
            listen-address option.





            share|improve this answer





















            • Tried it. dnsmasq doesn't see the traffic at all. It seems to only pickup on the ens256 interface, there is no OFFER, only the DISCOVER. Regardless, not sure that would help resolve the issue of setting source address as the lo:10 interface address (10.10.12.12)
              – Devin
              Jun 6 at 22:21










            • Is it possible that trying to use the loopback interface for non-localhost traffic is part of the problem?
              – DopeGhoti
              Jun 6 at 22:25










            • Typically it's assigned to the loopback with BGP because a loopback interface always remains up and keeps BGP peering established as long as there is a link available to reach the peer.
              – Devin
              Jun 6 at 22:52














            up vote
            0
            down vote













            If I understand well this is a problem with dnsmasq, the software offer a few solutions to your problem:
            interface to force listening of a specified interface e.g:



            interface=lo:10


            no-dhcp-interface to disable the distribution of DHCP on this interface e.g:



            no-dhcp-interface=ens256


            listen-address, looking like interface but specifying a binding IP instead e.g:



            listen-address=10.10.12.12


            From the dnsmasq documentation :



            -i, --interface=<interface name> Listen only on the specified interface(s). 
            Dnsmasq automatically adds the loopback (local) interface to the list of
            interfaces to use when the --interface option is used. If no --interface or

            -2, --no-dhcp-interface=<interface name>
            Do not provide DHCP or TFTP on the specified interface, but do provide DNS
            service.

            -a, --listen-address=<ipaddr>
            Listen on the given IP address(es). Both --interface and --listen-address
            options may be given, in which case the set of both interfaces and addresses
            is used. Note that if no --interface option is given, but --listen-address
            is, dnsmasq will not automatically listen on the loopback interface. To
            achieve this, its IP address, 127.0.0.1, must be explicitly given as a --
            listen-address option.





            share|improve this answer





















            • Tried it. dnsmasq doesn't see the traffic at all. It seems to only pickup on the ens256 interface, there is no OFFER, only the DISCOVER. Regardless, not sure that would help resolve the issue of setting source address as the lo:10 interface address (10.10.12.12)
              – Devin
              Jun 6 at 22:21










            • Is it possible that trying to use the loopback interface for non-localhost traffic is part of the problem?
              – DopeGhoti
              Jun 6 at 22:25










            • Typically it's assigned to the loopback with BGP because a loopback interface always remains up and keeps BGP peering established as long as there is a link available to reach the peer.
              – Devin
              Jun 6 at 22:52












            up vote
            0
            down vote










            up vote
            0
            down vote









            If I understand well this is a problem with dnsmasq, the software offer a few solutions to your problem:
            interface to force listening of a specified interface e.g:



            interface=lo:10


            no-dhcp-interface to disable the distribution of DHCP on this interface e.g:



            no-dhcp-interface=ens256


            listen-address, looking like interface but specifying a binding IP instead e.g:



            listen-address=10.10.12.12


            From the dnsmasq documentation :



            -i, --interface=<interface name> Listen only on the specified interface(s). 
            Dnsmasq automatically adds the loopback (local) interface to the list of
            interfaces to use when the --interface option is used. If no --interface or

            -2, --no-dhcp-interface=<interface name>
            Do not provide DHCP or TFTP on the specified interface, but do provide DNS
            service.

            -a, --listen-address=<ipaddr>
            Listen on the given IP address(es). Both --interface and --listen-address
            options may be given, in which case the set of both interfaces and addresses
            is used. Note that if no --interface option is given, but --listen-address
            is, dnsmasq will not automatically listen on the loopback interface. To
            achieve this, its IP address, 127.0.0.1, must be explicitly given as a --
            listen-address option.





            share|improve this answer













            If I understand well this is a problem with dnsmasq, the software offer a few solutions to your problem:
            interface to force listening of a specified interface e.g:



            interface=lo:10


            no-dhcp-interface to disable the distribution of DHCP on this interface e.g:



            no-dhcp-interface=ens256


            listen-address, looking like interface but specifying a binding IP instead e.g:



            listen-address=10.10.12.12


            From the dnsmasq documentation :



            -i, --interface=<interface name> Listen only on the specified interface(s). 
            Dnsmasq automatically adds the loopback (local) interface to the list of
            interfaces to use when the --interface option is used. If no --interface or

            -2, --no-dhcp-interface=<interface name>
            Do not provide DHCP or TFTP on the specified interface, but do provide DNS
            service.

            -a, --listen-address=<ipaddr>
            Listen on the given IP address(es). Both --interface and --listen-address
            options may be given, in which case the set of both interfaces and addresses
            is used. Note that if no --interface option is given, but --listen-address
            is, dnsmasq will not automatically listen on the loopback interface. To
            achieve this, its IP address, 127.0.0.1, must be explicitly given as a --
            listen-address option.






            share|improve this answer













            share|improve this answer



            share|improve this answer











            answered Jun 6 at 22:05









            Lencell

            694




            694











            • Tried it. dnsmasq doesn't see the traffic at all. It seems to only pickup on the ens256 interface, there is no OFFER, only the DISCOVER. Regardless, not sure that would help resolve the issue of setting source address as the lo:10 interface address (10.10.12.12)
              – Devin
              Jun 6 at 22:21










            • Is it possible that trying to use the loopback interface for non-localhost traffic is part of the problem?
              – DopeGhoti
              Jun 6 at 22:25










            • Typically it's assigned to the loopback with BGP because a loopback interface always remains up and keeps BGP peering established as long as there is a link available to reach the peer.
              – Devin
              Jun 6 at 22:52
















            • Tried it. dnsmasq doesn't see the traffic at all. It seems to only pickup on the ens256 interface, there is no OFFER, only the DISCOVER. Regardless, not sure that would help resolve the issue of setting source address as the lo:10 interface address (10.10.12.12)
              – Devin
              Jun 6 at 22:21










            • Is it possible that trying to use the loopback interface for non-localhost traffic is part of the problem?
              – DopeGhoti
              Jun 6 at 22:25










            • Typically it's assigned to the loopback with BGP because a loopback interface always remains up and keeps BGP peering established as long as there is a link available to reach the peer.
              – Devin
              Jun 6 at 22:52















            Tried it. dnsmasq doesn't see the traffic at all. It seems to only pickup on the ens256 interface, there is no OFFER, only the DISCOVER. Regardless, not sure that would help resolve the issue of setting source address as the lo:10 interface address (10.10.12.12)
            – Devin
            Jun 6 at 22:21




            Tried it. dnsmasq doesn't see the traffic at all. It seems to only pickup on the ens256 interface, there is no OFFER, only the DISCOVER. Regardless, not sure that would help resolve the issue of setting source address as the lo:10 interface address (10.10.12.12)
            – Devin
            Jun 6 at 22:21












            Is it possible that trying to use the loopback interface for non-localhost traffic is part of the problem?
            – DopeGhoti
            Jun 6 at 22:25




            Is it possible that trying to use the loopback interface for non-localhost traffic is part of the problem?
            – DopeGhoti
            Jun 6 at 22:25












            Typically it's assigned to the loopback with BGP because a loopback interface always remains up and keeps BGP peering established as long as there is a link available to reach the peer.
            – Devin
            Jun 6 at 22:52




            Typically it's assigned to the loopback with BGP because a loopback interface always remains up and keeps BGP peering established as long as there is a link available to reach the peer.
            – Devin
            Jun 6 at 22:52












             

            draft saved


            draft discarded


























             


            draft saved


            draft discarded














            StackExchange.ready(
            function ()
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f448296%2flinux-respond-with-source-address-of-a-virtual-interface%23new-answer', 'question_page');

            );

            Post as a guest













































































            Popular posts from this blog

            How to check contact read email or not when send email to Individual?

            Bahrain

            Postfix configuration issue with fips on centos 7; mailgun relay