Linux respond with source address of a virtual interface
Clash 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
network-interface routing dhcp
add a comment |Â
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
network-interface routing dhcp
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 alo*
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
add a comment |Â
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
network-interface routing dhcp
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
network-interface routing dhcp
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 alo*
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
add a comment |Â
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 alo*
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
add a comment |Â
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
add a comment |Â
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.
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
add a comment |Â
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
add a comment |Â
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
add a comment |Â
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
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
answered Jun 6 at 23:43
Devin
1163
1163
add a comment |Â
add a comment |Â
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.
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
add a comment |Â
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.
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
add a comment |Â
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.
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.
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
add a comment |Â
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
add a comment |Â
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
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
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
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