|
|
12
|
|
I don't know if it is affecting anything but you still have the
bridge defined
in /etc/network/interfaces. Also, you still have wlp2s0 on
10.1.1.0/24. Do
you want to define the wireless?
So 'blue' is to use 'yellow' to get to the internet. Do you have
iptables on
'yellow' set up to masquerade for 10.1.1.0/24
Bill
On 1/27/2018 7:10 PM, A wrote:
I meant to include the current
/etc/network/interfaces. Below. However, in the meantime I'm
getting different results. Perhaps due to the fact that I
changed "static" to "manuel". I also deleted the
bridge. Now, both machines can ping each other on the wired
interface, and yellow can still ping the 'Net. Blue cannot
ping the Internet.
It's unclear if the bridge-utils is truly
out of the picture, despite the tools reporting so. I suspect
this may still be an issue that will come back later when I
retry.
PING blue (10.1.1.14) 56(84) bytes of data.
64 bytes from blue (10.1.1.14): icmp_seq=1 ttl=64 time=0.353
ms
ping google.com
PING google.com (172.217.11.78) 56(84) bytes of data.
64 bytes from lax17s34-in-f14.1e100.net (172.217.11.78):
icmp_seq=1 ttl=56 time=23.4 ms
# ping yellow
PING yellow (127.0.1.1) 56(84) bytes of data.
64 bytes from yellow (127.0.1.1): icmp_seq=1 ttl=64 time=0.088
ms
^C
--- yellow ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.088/0.088/0.088/0.000 ms
# ping router
PING yellow (10.1.1.1) 56(84) bytes of data.
64 bytes from yellow (10.1.1.1): icmp_seq=1 ttl=64 time=0.077
ms
^C
--- yellow ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.077/0.077/0.077/0.000 ms
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~`
/etc/network/interfaces:
auto lo
iface lo inet loopback
dns-nameservers 10.1.1.1 8.8.8.8 8.8.4.4 50.23.197.95
dns-search FQDN
auto enp6s0
iface enp6s0 inet dhcp
dns-nameservers 10.1.1.1 8.8.8.8 8.8.4.4 50.23.197.95
dns-search FQDN
auto enp4s5
allow-hotplug enp4s5
iface enp4s5 inet manuel
gateway 10.1.1.1
network 10.1.1.0
netmask 255.255.255.0
broadcast 10.1.1.255
# Before we can change the address we have to bring the face
down
pre-up ip link set enp4s5 down
# I don't know if I can use two ups. I don't know the right way
to do this.
up ip address 0.0.0.0 dev enp4s5
up ip link set enp4s5 up
down ip link set enp4s5 down
allow-hotplug wlp2s0
iface wlp2s0 inet manuel
gateway 10.1.1.1
network 10.1.1.0
netmask 255.255.255.0
broadcast 10.1.1.255
# I don't know if I can use two pre-ups. I don't know the right
way to do this.
pre-up ip link set wlp2s0 down
pre-up ip address 0.0.0.0 dev wlp2s0
up ip link set wlp2s0 up
down ip link set wlp2s0 down
wireless-mode master
wireless-essid XXXXXXXXXXXXXX
wireless-channel 1
wpa-ssid XXXXXXXXXXXXXX
wpa-psk
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
gateway 10.1.1.1
auto br0
iface br0 inet static
address 10.1.1.1
network 10.1.1.0
netmask 255.255.255.0
broadcast 10.1.1.255
bridge-ports enp4s5 wlp2s0
On 01/27/2018 03:20 PM, A wrote:
On 01/27/2018 01:28 PM, Simon
Hobson wrote:
I did originally
have two separate subnets with a /28 CIDR, but I was
unable to reach the Internet from blue and someone
suggested I have one subnet in order to act as a typical
home router. So I reconfigured everything and it's now
borked worse than it was. Said person disappeared
shortly after of course.
There is no commercial router. Yellow is the router,
gateway, access point, dhcp server, dns server, firewall
(iptables) and more.
OK, so this box is your gateway, AP, etc, etc. In that
case I believe that your setup is fundamentally broken - you
have TWO SEPARATE networks (one wired, one wireless) running
the same subnet.
Yes, that's how I was told to set it up by a helpful
individual. I was told since it was one subnet, no routing
would be needed. The wireless & wired interfaces would be
bridged. Seemed reasonable. It sounds like you are suggesting
exactly the same thing so "fundamentally broken" seems a bit
harsh.
Thus devices on the wired network cannot talk to devices
on the WiFi and vice-verca.
Bear in mind that I've not used WiFi in this manner (I'm
used to using external APs), so I am unsure of some of the
details. If you want to run a single unified network then
you will need to create a bridge, and put the wired and
wireless adapters into that bridge - and put your address
10.1.1.1/24 onto the bridge. You will then have one network,
and the bridge software will pass packets between them, as
well as keeping track of which clients are in which network
segment.
I removed the bridge because I was unable to reach the Internet
from yellow (nor blue). And that is how things stand now.
Bridge up, Internet down. Bridge down, Internet up.
As far as (almost) all software on your box is concerned,
you just deal with one interface (the bridge, eg br0). What
I am unsure about is how dhcpd behaves in this case -
hopefully someone who's run this setup can comment ? I would
hope that it would use the bridge interface in the same
manner as it would use a "real" one, but there can be some
subtle differences.
I had it working with the bridge at one point - each box could
ping the other on both wired & wireless, but blue couldn't
reach the Internet. Lets see if we can put it back.
.... blue now receives an IP of .14; neither machine can ping
the other, though each can ping its own assigned IP.
# brctl show
bridge name bridge id STP enabled interfaces
br0 8000.7085c23b1324 no enp4s5
enp6s0
$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue
state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: enp4s5: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500
qdisc pfifo_fast master br0 state UP group default qlen 1000
link/ether c8:3a:35:da:42:72 brd ff:ff:ff:ff:ff:ff
inet 10.1.1.1/24 brd 10.1.1.255 scope global enp4s5
valid_lft forever preferred_lft forever
3: enp6s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500
qdisc pfifo_fast master br0 state UP group default qlen 1000
link/ether 70:85:c2:3b:13:24 brd ff:ff:ff:ff:ff:ff
inet [xx.xx.xx.xx]/20 brd 255.255.255.255 scope global
enp6s0
valid_lft forever preferred_lft forever
inet6 fe80::7285:c2ff:fe3b:1324/64 scope link
valid_lft forever preferred_lft forever
4: wlp2s0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500
qdisc noqueue state DOWN group default qlen 1000
link/ether f0:7d:68:c1:b4:13 brd ff:ff:ff:ff:ff:ff
inet 10.1.1.10/24 brd 10.1.1.255 scope global wlp2s0
valid_lft forever preferred_lft forever
5: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc
noqueue state UP group default qlen 1000
link/ether 70:85:c2:3b:13:24 brd ff:ff:ff:ff:ff:ff
inet 10.1.1.1/24 brd 10.1.1.255 scope global br0
valid_lft forever preferred_lft forever
inet6 fe80::7285:c2ff:fe3b:1324/64 scope link
valid_lft forever preferred_lft forever
# ip route
default via 174.xx.yy.1 dev enp6s0
10.1.1.0/24 dev enp4s5 proto kernel scope link src 10.1.1.1
174.xx.yy.0/20 dev enp6s0 proto kernel scope link src
174.xx.bb.zz
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
|
|
|
On 01/27/2018 04:22 PM, Bill Shirley
wrote:
I don't know if it is affecting anything but you still have the
bridge defined
in /etc/network/interfaces. Also, you still have wlp2s0 on
10.1.1.0/24. Do
you want to define the wireless?
Yes. I just finished responding to your prior email. I need to run
out for a few minutes before it gets dark. Back in 30.
So 'blue' is to use 'yellow' to get to the internet. Do you have
iptables on
'yellow' set up to masquerade for 10.1.1.0/24
This is what I have at the moment so far. I see an error with
FOUR. Back in 30.
-A PREROUTING -i enp6s0 -p tcp -m multiport --dports 80,443 -j DNAT
--to-destination 10.1.1.1
-A FORWARD -i enp6s0 -o wlp2s0 -m conntrack --ctstate
RELATED,ESTABLISHED -m comment --comment THREE -j ACCEPT
-A FORWARD -d 10.1.1.0/32 -i enp4s5 -o enp6s0 -m comment --comment
FOUR -j ACCEPT
-A FORWARD ! -d 10.1.1.0/32 -o enp6s0 -m comment --comment SEVEN -j
ACCEPT
-A FORWARD -d 10.1.1.0/32 -o br0 -m conntrack --ctstate
RELATED,ESTABLISHED -m comment --comment EIGHT -j ACCEPT
Bill
On 1/27/2018 7:10 PM, A wrote:
I meant to include the current
/etc/network/interfaces. Below. However, in the meantime
I'm getting different results. Perhaps due to the fact that
I changed "static" to "manuel". I also deleted the
bridge. Now, both machines can ping each other on the wired
interface, and yellow can still ping the 'Net. Blue cannot
ping the Internet.
It's unclear if the bridge-utils is truly
out of the picture, despite the tools reporting so. I
suspect this may still be an issue that will come back later
when I retry.
PING blue (10.1.1.14) 56(84) bytes of
data.
64 bytes from blue (10.1.1.14): icmp_seq=1 ttl=64 time=0.353
ms
ping google.com
PING google.com (172.217.11.78) 56(84) bytes of data.
64 bytes from lax17s34-in-f14.1e100.net (172.217.11.78):
icmp_seq=1 ttl=56 time=23.4 ms
# ping yellow
PING yellow (127.0.1.1) 56(84) bytes of data.
64 bytes from yellow (127.0.1.1): icmp_seq=1 ttl=64
time=0.088 ms
^C
--- yellow ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.088/0.088/0.088/0.000 ms
# ping router
PING yellow (10.1.1.1) 56(84) bytes of data.
64 bytes from yellow (10.1.1.1): icmp_seq=1 ttl=64
time=0.077 ms
^C
--- yellow ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.077/0.077/0.077/0.000 ms
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~`
/etc/network/interfaces:
auto lo
iface lo inet loopback
dns-nameservers 10.1.1.1 8.8.8.8 8.8.4.4 50.23.197.95
dns-search FQDN
auto enp6s0
iface enp6s0 inet dhcp
dns-nameservers 10.1.1.1 8.8.8.8 8.8.4.4 50.23.197.95
dns-search FQDN
auto enp4s5
allow-hotplug enp4s5
iface enp4s5 inet manuel
gateway 10.1.1.1
network 10.1.1.0
netmask 255.255.255.0
broadcast 10.1.1.255
# Before we can change the address we have to bring the face
down
pre-up ip link set enp4s5 down
# I don't know if I can use two ups. I don't know the right way
to do this.
up ip address 0.0.0.0 dev enp4s5
up ip link set enp4s5 up
down ip link set enp4s5 down
allow-hotplug wlp2s0
iface wlp2s0 inet manuel
gateway 10.1.1.1
network 10.1.1.0
netmask 255.255.255.0
broadcast 10.1.1.255
# I don't know if I can use two pre-ups. I don't know the right
way to do this.
pre-up ip link set wlp2s0 down
pre-up ip address 0.0.0.0 dev wlp2s0
up ip link set wlp2s0 up
down ip link set wlp2s0 down
wireless-mode master
wireless-essid XXXXXXXXXXXXXX
wireless-channel 1
wpa-ssid XXXXXXXXXXXXXX
wpa-psk
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
gateway 10.1.1.1
auto br0
iface br0 inet static
address 10.1.1.1
network 10.1.1.0
netmask 255.255.255.0
broadcast 10.1.1.255
bridge-ports enp4s5 wlp2s0
On 01/27/2018 03:20 PM, A wrote:
On 01/27/2018 01:28 PM, Simon
Hobson wrote:
I did originally
have two separate subnets with a /28 CIDR, but I was
unable to reach the Internet from blue and someone
suggested I have one subnet in order to act as a
typical home router. So I reconfigured everything and
it's now borked worse than it was. Said person
disappeared shortly after of course.
There is no commercial router. Yellow is the router,
gateway, access point, dhcp server, dns server,
firewall (iptables) and more.
OK, so this box is your gateway, AP, etc, etc. In that
case I believe that your setup is fundamentally broken -
you have TWO SEPARATE networks (one wired, one wireless)
running the same subnet.
Yes, that's how I was told to set it up by a helpful
individual. I was told since it was one subnet, no routing
would be needed. The wireless & wired interfaces would be
bridged. Seemed reasonable. It sounds like you are
suggesting exactly the same thing so "fundamentally broken"
seems a bit harsh.
Thus devices on the wired network cannot talk to
devices on the WiFi and vice-verca.
Bear in mind that I've not used WiFi in this manner
(I'm used to using external APs), so I am unsure of some
of the details. If you want to run a single unified
network then you will need to create a bridge, and put the
wired and wireless adapters into that bridge - and put
your address 10.1.1.1/24 onto the bridge. You will then
have one network, and the bridge software will pass
packets between them, as well as keeping track of which
clients are in which network segment.
I removed the bridge because I was unable to reach the
Internet from yellow (nor blue). And that is how things stand
now. Bridge up, Internet down. Bridge down, Internet up.
As far as (almost) all software on your box is
concerned, you just deal with one interface (the bridge,
eg br0). What I am unsure about is how dhcpd behaves in
this case - hopefully someone who's run this setup can
comment ? I would hope that it would use the bridge
interface in the same manner as it would use a "real" one,
but there can be some subtle differences.
I had it working with the bridge at one point - each box could
ping the other on both wired & wireless, but blue couldn't
reach the Internet. Lets see if we can put it back.
.... blue now receives an IP of .14; neither machine can ping
the other, though each can ping its own assigned IP.
# brctl show
bridge name bridge id STP enabled interfaces
br0 8000.7085c23b1324 no enp4s5
enp6s0
$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue
state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: enp4s5: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500
qdisc pfifo_fast master br0 state UP group default qlen 1000
link/ether c8:3a:35:da:42:72 brd ff:ff:ff:ff:ff:ff
inet 10.1.1.1/24 brd 10.1.1.255 scope global enp4s5
valid_lft forever preferred_lft forever
3: enp6s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500
qdisc pfifo_fast master br0 state UP group default qlen 1000
link/ether 70:85:c2:3b:13:24 brd ff:ff:ff:ff:ff:ff
inet [xx.xx.xx.xx]/20 brd 255.255.255.255 scope global
enp6s0
valid_lft forever preferred_lft forever
inet6 fe80::7285:c2ff:fe3b:1324/64 scope link
valid_lft forever preferred_lft forever
4: wlp2s0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500
qdisc noqueue state DOWN group default qlen 1000
link/ether f0:7d:68:c1:b4:13 brd ff:ff:ff:ff:ff:ff
inet 10.1.1.10/24 brd 10.1.1.255 scope global wlp2s0
valid_lft forever preferred_lft forever
5: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc
noqueue state UP group default qlen 1000
link/ether 70:85:c2:3b:13:24 brd ff:ff:ff:ff:ff:ff
inet 10.1.1.1/24 brd 10.1.1.255 scope global br0
valid_lft forever preferred_lft forever
inet6 fe80::7285:c2ff:fe3b:1324/64 scope link
valid_lft forever preferred_lft forever
# ip route
default via 174.xx.yy.1 dev enp6s0
10.1.1.0/24 dev enp4s5 proto kernel scope link src 10.1.1.1
174.xx.yy.0/20 dev enp6s0 proto kernel scope link src
174.xx.bb.zz
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
|
|
|
You're looking in the wrong table. You want 'iptables -t nat'.
You need an entry something like:
iptables -t nat -A POSTROUTING -o enp6s0
-s 10.1.1.0/24 -j MASQUERADE
I don't craft my iptables by hand; I use Shorewall.
Bill
On 1/27/2018 7:52 PM, A wrote:
On 01/27/2018 04:22 PM, Bill Shirley
wrote:
I don't know if it is affecting anything but you still have the
bridge defined
in /etc/network/interfaces. Also, you still have wlp2s0 on
10.1.1.0/24. Do
you want to define the wireless?
Yes. I just finished responding to your prior email. I need to
run out for a few minutes before it gets dark. Back in 30.
So 'blue' is to use 'yellow' to get to the internet. Do you
have iptables on
'yellow' set up to masquerade for 10.1.1.0/24
This is what I have at the moment so far. I see an error with
FOUR. Back in 30.
-A PREROUTING -i enp6s0 -p tcp -m multiport --dports 80,443 -j
DNAT --to-destination 10.1.1.1
-A FORWARD -i enp6s0 -o wlp2s0 -m conntrack --ctstate
RELATED,ESTABLISHED -m comment --comment THREE -j ACCEPT
-A FORWARD -d 10.1.1.0/32 -i enp4s5 -o enp6s0 -m comment --comment
FOUR -j ACCEPT
-A FORWARD ! -d 10.1.1.0/32 -o enp6s0 -m comment --comment SEVEN
-j ACCEPT
-A FORWARD -d 10.1.1.0/32 -o br0 -m conntrack --ctstate
RELATED,ESTABLISHED -m comment --comment EIGHT -j ACCEPT
Bill
On 1/27/2018 7:10 PM, A wrote:
I meant to include the current
/etc/network/interfaces. Below. However, in the meantime
I'm getting different results. Perhaps due to the fact
that I changed "static" to "manuel". I also deleted
the bridge. Now, both machines can ping each other on the
wired interface, and yellow can still ping the 'Net.
Blue cannot ping the Internet.
It's unclear if the bridge-utils is
truly out of the picture, despite the tools reporting so.
I suspect this may still be an issue that will come back
later when I retry.
PING blue (10.1.1.14) 56(84) bytes of
data.
64 bytes from blue (10.1.1.14): icmp_seq=1 ttl=64
time=0.353 ms
ping google.com
PING google.com (172.217.11.78) 56(84) bytes of data.
64 bytes from lax17s34-in-f14.1e100.net (172.217.11.78):
icmp_seq=1 ttl=56 time=23.4 ms
# ping yellow
PING yellow (127.0.1.1) 56(84) bytes of data.
64 bytes from yellow (127.0.1.1): icmp_seq=1 ttl=64
time=0.088 ms
^C
--- yellow ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time
0ms
rtt min/avg/max/mdev = 0.088/0.088/0.088/0.000 ms
# ping router
PING yellow (10.1.1.1) 56(84) bytes of data.
64 bytes from yellow (10.1.1.1): icmp_seq=1 ttl=64
time=0.077 ms
^C
--- yellow ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time
0ms
rtt min/avg/max/mdev = 0.077/0.077/0.077/0.000 ms
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~`
/etc/network/interfaces:
auto lo
iface lo inet loopback
dns-nameservers 10.1.1.1 8.8.8.8 8.8.4.4 50.23.197.95
dns-search FQDN
auto enp6s0
iface enp6s0 inet dhcp
dns-nameservers 10.1.1.1 8.8.8.8 8.8.4.4 50.23.197.95
dns-search FQDN
auto enp4s5
allow-hotplug enp4s5
iface enp4s5 inet manuel
gateway 10.1.1.1
network 10.1.1.0
netmask 255.255.255.0
broadcast 10.1.1.255
# Before we can change the address we have to bring the
face down
pre-up ip link set enp4s5 down
# I don't know if I can use two ups. I don't know the right
way to do this.
up ip address 0.0.0.0 dev enp4s5
up ip link set enp4s5 up
down ip link set enp4s5 down
allow-hotplug wlp2s0
iface wlp2s0 inet manuel
gateway 10.1.1.1
network 10.1.1.0
netmask 255.255.255.0
broadcast 10.1.1.255
# I don't know if I can use two pre-ups. I don't know the
right way to do this.
pre-up ip link set wlp2s0 down
pre-up ip address 0.0.0.0 dev wlp2s0
up ip link set wlp2s0 up
down ip link set wlp2s0 down
wireless-mode master
wireless-essid XXXXXXXXXXXXXX
wireless-channel 1
wpa-ssid XXXXXXXXXXXXXX
wpa-psk
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
gateway 10.1.1.1
auto br0
iface br0 inet static
address 10.1.1.1
network 10.1.1.0
netmask 255.255.255.0
broadcast 10.1.1.255
bridge-ports enp4s5 wlp2s0
On 01/27/2018 03:20 PM, A wrote:
On 01/27/2018 01:28 PM, Simon
Hobson wrote:
I did originally
have two separate subnets with a /28 CIDR, but I was
unable to reach the Internet from blue and someone
suggested I have one subnet in order to act as a
typical home router. So I reconfigured everything
and it's now borked worse than it was. Said person
disappeared shortly after of course.
There is no commercial router. Yellow is the
router, gateway, access point, dhcp server, dns
server, firewall (iptables) and more.
OK, so this box is your gateway, AP, etc, etc. In
that case I believe that your setup is fundamentally
broken - you have TWO SEPARATE networks (one wired, one
wireless) running the same subnet.
Yes, that's how I was told to set it up by a helpful
individual. I was told since it was one subnet, no routing
would be needed. The wireless & wired interfaces would
be bridged. Seemed reasonable. It sounds like you are
suggesting exactly the same thing so "fundamentally broken"
seems a bit harsh.
Thus devices on the wired network cannot talk to
devices on the WiFi and vice-verca.
Bear in mind that I've not used WiFi in this manner
(I'm used to using external APs), so I am unsure of some
of the details. If you want to run a single unified
network then you will need to create a bridge, and put
the wired and wireless adapters into that bridge - and
put your address 10.1.1.1/24 onto the bridge. You will
then have one network, and the bridge software will pass
packets between them, as well as keeping track of which
clients are in which network segment.
I removed the bridge because I was unable to reach the
Internet from yellow (nor blue). And that is how things
stand now. Bridge up, Internet down. Bridge down, Internet
up.
As far as (almost) all software on your box is
concerned, you just deal with one interface (the bridge,
eg br0). What I am unsure about is how dhcpd behaves in
this case - hopefully someone who's run this setup can
comment ? I would hope that it would use the bridge
interface in the same manner as it would use a "real"
one, but there can be some subtle differences.
I had it working with the bridge at one point - each box
could ping the other on both wired & wireless, but blue
couldn't reach the Internet. Lets see if we can put it
back.
.... blue now receives an IP of .14; neither machine can
ping the other, though each can ping its own assigned IP.
# brctl show
bridge name bridge id STP enabled interfaces
br0 8000.7085c23b1324 no enp4s5
enp6s0
$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue
state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: enp4s5: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500
qdisc pfifo_fast master br0 state UP group default qlen 1000
link/ether c8:3a:35:da:42:72 brd ff:ff:ff:ff:ff:ff
inet 10.1.1.1/24 brd 10.1.1.255 scope global enp4s5
valid_lft forever preferred_lft forever
3: enp6s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500
qdisc pfifo_fast master br0 state UP group default qlen 1000
link/ether 70:85:c2:3b:13:24 brd ff:ff:ff:ff:ff:ff
inet [xx.xx.xx.xx]/20 brd 255.255.255.255 scope global
enp6s0
valid_lft forever preferred_lft forever
inet6 fe80::7285:c2ff:fe3b:1324/64 scope link
valid_lft forever preferred_lft forever
4: wlp2s0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu
1500 qdisc noqueue state DOWN group default qlen 1000
link/ether f0:7d:68:c1:b4:13 brd ff:ff:ff:ff:ff:ff
inet 10.1.1.10/24 brd 10.1.1.255 scope global wlp2s0
valid_lft forever preferred_lft forever
5: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500
qdisc noqueue state UP group default qlen 1000
link/ether 70:85:c2:3b:13:24 brd ff:ff:ff:ff:ff:ff
inet 10.1.1.1/24 brd 10.1.1.255 scope global br0
valid_lft forever preferred_lft forever
inet6 fe80::7285:c2ff:fe3b:1324/64 scope link
valid_lft forever preferred_lft forever
# ip route
default via 174.xx.yy.1 dev enp6s0
10.1.1.0/24 dev enp4s5 proto kernel scope link src
10.1.1.1
174.xx.yy.0/20 dev enp6s0 proto kernel scope link src
174.xx.bb.zz
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
|
|
|
Also in the entries you've shown: FOUR, SEVEN, and EIGHT are
using /32 which I think should be /24 I would think. EIGHT is a
rule for the bridge, do you need that?
Bill
On 1/27/2018 9:24 PM, Bill Shirley
wrote:
You're looking in the wrong table. You want 'iptables -t nat'.
You need an entry something like:
iptables -t nat -A POSTROUTING -o enp6s0
-s 10.1.1.0/24 -j MASQUERADE
I don't craft my iptables by hand; I use Shorewall.
Bill
On 1/27/2018 7:52 PM, A wrote:
On 01/27/2018 04:22 PM, Bill
Shirley wrote:
I don't know if it is affecting anything but you still have
the bridge defined
in /etc/network/interfaces. Also, you still have wlp2s0 on
10.1.1.0/24. Do
you want to define the wireless?
Yes. I just finished responding to your prior email. I need to
run out for a few minutes before it gets dark. Back in 30.
So 'blue' is to use 'yellow' to get to the internet. Do you
have iptables on
'yellow' set up to masquerade for 10.1.1.0/24
This is what I have at the moment so far. I see an error with
FOUR. Back in 30.
-A PREROUTING -i enp6s0 -p tcp -m multiport --dports 80,443 -j
DNAT --to-destination 10.1.1.1
-A FORWARD -i enp6s0 -o wlp2s0 -m conntrack --ctstate
RELATED,ESTABLISHED -m comment --comment THREE -j ACCEPT
-A FORWARD -d 10.1.1.0/32 -i enp4s5 -o enp6s0 -m comment
--comment FOUR -j ACCEPT
-A FORWARD ! -d 10.1.1.0/32 -o enp6s0 -m comment --comment SEVEN
-j ACCEPT
-A FORWARD -d 10.1.1.0/32 -o br0 -m conntrack --ctstate
RELATED,ESTABLISHED -m comment --comment EIGHT -j ACCEPT
Bill
On 1/27/2018 7:10 PM, A wrote:
I meant to include the current
/etc/network/interfaces. Below. However, in the
meantime I'm getting different results. Perhaps due to
the fact that I changed "static" to "manuel". I also deleted
the bridge. Now, both machines can ping each other on
the wired interface, and yellow can still ping the
'Net. Blue cannot ping the Internet.
It's unclear if the bridge-utils is
truly out of the picture, despite the tools reporting
so. I suspect this may still be an issue that will come
back later when I retry.
PING blue (10.1.1.14) 56(84) bytes of
data.
64 bytes from blue (10.1.1.14): icmp_seq=1 ttl=64
time=0.353 ms
ping google.com
PING google.com (172.217.11.78) 56(84) bytes of data.
64 bytes from lax17s34-in-f14.1e100.net (172.217.11.78):
icmp_seq=1 ttl=56 time=23.4 ms
# ping yellow
PING yellow (127.0.1.1) 56(84) bytes of data.
64 bytes from yellow (127.0.1.1): icmp_seq=1 ttl=64
time=0.088 ms
^C
--- yellow ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time
0ms
rtt min/avg/max/mdev = 0.088/0.088/0.088/0.000 ms
# ping router
PING yellow (10.1.1.1) 56(84) bytes of data.
64 bytes from yellow (10.1.1.1): icmp_seq=1 ttl=64
time=0.077 ms
^C
--- yellow ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time
0ms
rtt min/avg/max/mdev = 0.077/0.077/0.077/0.000 ms
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~`
/etc/network/interfaces:
auto lo
iface lo inet loopback
dns-nameservers 10.1.1.1 8.8.8.8 8.8.4.4 50.23.197.95
dns-search FQDN
auto enp6s0
iface enp6s0 inet dhcp
dns-nameservers 10.1.1.1 8.8.8.8 8.8.4.4 50.23.197.95
dns-search FQDN
auto enp4s5
allow-hotplug enp4s5
iface enp4s5 inet manuel
gateway 10.1.1.1
network 10.1.1.0
netmask 255.255.255.0
broadcast 10.1.1.255
# Before we can change the address we have to bring the
face down
pre-up ip link set enp4s5 down
# I don't know if I can use two ups. I don't know the right
way to do this.
up ip address 0.0.0.0 dev enp4s5
up ip link set enp4s5 up
down ip link set enp4s5 down
allow-hotplug wlp2s0
iface wlp2s0 inet manuel
gateway 10.1.1.1
network 10.1.1.0
netmask 255.255.255.0
broadcast 10.1.1.255
# I don't know if I can use two pre-ups. I don't know the
right way to do this.
pre-up ip link set wlp2s0 down
pre-up ip address 0.0.0.0 dev wlp2s0
up ip link set wlp2s0 up
down ip link set wlp2s0 down
wireless-mode master
wireless-essid XXXXXXXXXXXXXX
wireless-channel 1
wpa-ssid XXXXXXXXXXXXXX
wpa-psk
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
gateway 10.1.1.1
auto br0
iface br0 inet static
address 10.1.1.1
network 10.1.1.0
netmask 255.255.255.0
broadcast 10.1.1.255
bridge-ports enp4s5 wlp2s0
On 01/27/2018 03:20 PM, A
wrote:
On 01/27/2018 01:28 PM, Simon
Hobson wrote:
I did
originally have two separate subnets with a /28
CIDR, but I was unable to reach the Internet from
blue and someone suggested I have one subnet in
order to act as a typical home router. So I
reconfigured everything and it's now borked worse
than it was. Said person disappeared shortly
after of course.
There is no commercial router. Yellow is the
router, gateway, access point, dhcp server, dns
server, firewall (iptables) and more.
OK, so this box is your gateway, AP, etc, etc. In
that case I believe that your setup is fundamentally
broken - you have TWO SEPARATE networks (one wired,
one wireless) running the same subnet.
Yes, that's how I was told to set it up by a helpful
individual. I was told since it was one subnet, no
routing would be needed. The wireless & wired
interfaces would be bridged. Seemed reasonable. It
sounds like you are suggesting exactly the same thing so
"fundamentally broken" seems a bit harsh.
Thus devices on the wired network cannot talk to
devices on the WiFi and vice-verca.
Bear in mind that I've not used WiFi in this manner
(I'm used to using external APs), so I am unsure of
some of the details. If you want to run a single
unified network then you will need to create a bridge,
and put the wired and wireless adapters into that
bridge - and put your address 10.1.1.1/24 onto the
bridge. You will then have one network, and the bridge
software will pass packets between them, as well as
keeping track of which clients are in which network
segment.
I removed the bridge because I was unable to reach the
Internet from yellow (nor blue). And that is how things
stand now. Bridge up, Internet down. Bridge down,
Internet up.
As far as (almost) all software on your box is
concerned, you just deal with one interface (the
bridge, eg br0). What I am unsure about is how dhcpd
behaves in this case - hopefully someone who's run
this setup can comment ? I would hope that it would
use the bridge interface in the same manner as it
would use a "real" one, but there can be some subtle
differences.
I had it working with the bridge at one point - each box
could ping the other on both wired & wireless, but
blue couldn't reach the Internet. Lets see if we can put
it back.
.... blue now receives an IP of .14; neither machine can
ping the other, though each can ping its own assigned IP.
# brctl show
bridge name bridge id STP enabled interfaces
br0 8000.7085c23b1324 no
enp4s5
enp6s0
$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc
noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: enp4s5: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu
1500 qdisc pfifo_fast master br0 state UP group default
qlen 1000
link/ether c8:3a:35:da:42:72 brd ff:ff:ff:ff:ff:ff
inet 10.1.1.1/24 brd 10.1.1.255 scope global enp4s5
valid_lft forever preferred_lft forever
3: enp6s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu
1500 qdisc pfifo_fast master br0 state UP group default
qlen 1000
link/ether 70:85:c2:3b:13:24 brd ff:ff:ff:ff:ff:ff
inet [xx.xx.xx.xx]/20 brd 255.255.255.255 scope global
enp6s0
valid_lft forever preferred_lft forever
inet6 fe80::7285:c2ff:fe3b:1324/64 scope link
valid_lft forever preferred_lft forever
4: wlp2s0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu
1500 qdisc noqueue state DOWN group default qlen 1000
link/ether f0:7d:68:c1:b4:13 brd ff:ff:ff:ff:ff:ff
inet 10.1.1.10/24 brd 10.1.1.255 scope global wlp2s0
valid_lft forever preferred_lft forever
5: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500
qdisc noqueue state UP group default qlen 1000
link/ether 70:85:c2:3b:13:24 brd ff:ff:ff:ff:ff:ff
inet 10.1.1.1/24 brd 10.1.1.255 scope global br0
valid_lft forever preferred_lft forever
inet6 fe80::7285:c2ff:fe3b:1324/64 scope link
valid_lft forever preferred_lft forever
# ip route
default via 174.xx.yy.1 dev enp6s0
10.1.1.0/24 dev enp4s5 proto kernel scope link src
10.1.1.1
174.xx.yy.0/20 dev enp6s0 proto kernel scope link src
174.xx.bb.zz
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
|
|
|
On 01/27/2018 06:24 PM, Bill Shirley
wrote:
You're looking in the wrong table. You want 'iptables -t nat'.
You need an entry something like:
iptables -t nat -A POSTROUTING -o enp6s0
-s 10.1.1.0/24 -j MASQUERADE
Forgot that one, sorry. I've been showing you grepped output. This
is from the nat table.
-A POSTROUTING -s 10.1.1.0/32 -o enp6s0 -j MASQUERADE
I don't craft my iptables by hand; I use Shorewall.
Bill
On 1/27/2018 7:52 PM, A wrote:
On 01/27/2018 04:22 PM, Bill
Shirley wrote:
I don't know if it is affecting anything but you still have
the bridge defined
in /etc/network/interfaces. Also, you still have wlp2s0 on
10.1.1.0/24. Do
you want to define the wireless?
Yes. I just finished responding to your prior email. I need to
run out for a few minutes before it gets dark. Back in 30.
So 'blue' is to use 'yellow' to get to the internet. Do you
have iptables on
'yellow' set up to masquerade for 10.1.1.0/24
This is what I have at the moment so far. I see an error with
FOUR. Back in 30.
-A PREROUTING -i enp6s0 -p tcp -m multiport --dports 80,443 -j
DNAT --to-destination 10.1.1.1
-A FORWARD -i enp6s0 -o wlp2s0 -m conntrack --ctstate
RELATED,ESTABLISHED -m comment --comment THREE -j ACCEPT
-A FORWARD -d 10.1.1.0/32 -i enp4s5 -o enp6s0 -m comment
--comment FOUR -j ACCEPT
-A FORWARD ! -d 10.1.1.0/32 -o enp6s0 -m comment --comment SEVEN
-j ACCEPT
-A FORWARD -d 10.1.1.0/32 -o br0 -m conntrack --ctstate
RELATED,ESTABLISHED -m comment --comment EIGHT -j ACCEPT
Bill
On 1/27/2018 7:10 PM, A wrote:
I meant to include the current
/etc/network/interfaces. Below. However, in the
meantime I'm getting different results. Perhaps due to
the fact that I changed "static" to "manuel". I also deleted
the bridge. Now, both machines can ping each other on
the wired interface, and yellow can still ping the
'Net. Blue cannot ping the Internet.
It's unclear if the bridge-utils is
truly out of the picture, despite the tools reporting
so. I suspect this may still be an issue that will come
back later when I retry.
PING blue (10.1.1.14) 56(84) bytes of
data.
64 bytes from blue (10.1.1.14): icmp_seq=1 ttl=64
time=0.353 ms
ping google.com
PING google.com (172.217.11.78) 56(84) bytes of data.
64 bytes from lax17s34-in-f14.1e100.net (172.217.11.78):
icmp_seq=1 ttl=56 time=23.4 ms
# ping yellow
PING yellow (127.0.1.1) 56(84) bytes of data.
64 bytes from yellow (127.0.1.1): icmp_seq=1 ttl=64
time=0.088 ms
^C
--- yellow ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time
0ms
rtt min/avg/max/mdev = 0.088/0.088/0.088/0.000 ms
# ping router
PING yellow (10.1.1.1) 56(84) bytes of data.
64 bytes from yellow (10.1.1.1): icmp_seq=1 ttl=64
time=0.077 ms
^C
--- yellow ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time
0ms
rtt min/avg/max/mdev = 0.077/0.077/0.077/0.000 ms
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~`
/etc/network/interfaces:
auto lo
iface lo inet loopback
dns-nameservers 10.1.1.1 8.8.8.8 8.8.4.4 50.23.197.95
dns-search FQDN
auto enp6s0
iface enp6s0 inet dhcp
dns-nameservers 10.1.1.1 8.8.8.8 8.8.4.4 50.23.197.95
dns-search FQDN
auto enp4s5
allow-hotplug enp4s5
iface enp4s5 inet manuel
gateway 10.1.1.1
network 10.1.1.0
netmask 255.255.255.0
broadcast 10.1.1.255
# Before we can change the address we have to bring the
face down
pre-up ip link set enp4s5 down
# I don't know if I can use two ups. I don't know the right
way to do this.
up ip address 0.0.0.0 dev enp4s5
up ip link set enp4s5 up
down ip link set enp4s5 down
allow-hotplug wlp2s0
iface wlp2s0 inet manuel
gateway 10.1.1.1
network 10.1.1.0
netmask 255.255.255.0
broadcast 10.1.1.255
# I don't know if I can use two pre-ups. I don't know the
right way to do this.
pre-up ip link set wlp2s0 down
pre-up ip address 0.0.0.0 dev wlp2s0
up ip link set wlp2s0 up
down ip link set wlp2s0 down
wireless-mode master
wireless-essid XXXXXXXXXXXXXX
wireless-channel 1
wpa-ssid XXXXXXXXXXXXXX
wpa-psk
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
gateway 10.1.1.1
auto br0
iface br0 inet static
address 10.1.1.1
network 10.1.1.0
netmask 255.255.255.0
broadcast 10.1.1.255
bridge-ports enp4s5 wlp2s0
On 01/27/2018 03:20 PM, A
wrote:
On 01/27/2018 01:28 PM, Simon
Hobson wrote:
I did
originally have two separate subnets with a /28
CIDR, but I was unable to reach the Internet from
blue and someone suggested I have one subnet in
order to act as a typical home router. So I
reconfigured everything and it's now borked worse
than it was. Said person disappeared shortly
after of course.
There is no commercial router. Yellow is the
router, gateway, access point, dhcp server, dns
server, firewall (iptables) and more.
OK, so this box is your gateway, AP, etc, etc. In
that case I believe that your setup is fundamentally
broken - you have TWO SEPARATE networks (one wired,
one wireless) running the same subnet.
Yes, that's how I was told to set it up by a helpful
individual. I was told since it was one subnet, no
routing would be needed. The wireless & wired
interfaces would be bridged. Seemed reasonable. It
sounds like you are suggesting exactly the same thing so
"fundamentally broken" seems a bit harsh.
Thus devices on the wired network cannot talk to
devices on the WiFi and vice-verca.
Bear in mind that I've not used WiFi in this manner
(I'm used to using external APs), so I am unsure of
some of the details. If you want to run a single
unified network then you will need to create a bridge,
and put the wired and wireless adapters into that
bridge - and put your address 10.1.1.1/24 onto the
bridge. You will then have one network, and the bridge
software will pass packets between them, as well as
keeping track of which clients are in which network
segment.
I removed the bridge because I was unable to reach the
Internet from yellow (nor blue). And that is how things
stand now. Bridge up, Internet down. Bridge down,
Internet up.
As far as (almost) all software on your box is
concerned, you just deal with one interface (the
bridge, eg br0). What I am unsure about is how dhcpd
behaves in this case - hopefully someone who's run
this setup can comment ? I would hope that it would
use the bridge interface in the same manner as it
would use a "real" one, but there can be some subtle
differences.
I had it working with the bridge at one point - each box
could ping the other on both wired & wireless, but
blue couldn't reach the Internet. Lets see if we can put
it back.
.... blue now receives an IP of .14; neither machine can
ping the other, though each can ping its own assigned IP.
# brctl show
bridge name bridge id STP enabled interfaces
br0 8000.7085c23b1324 no
enp4s5
enp6s0
$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc
noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: enp4s5: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu
1500 qdisc pfifo_fast master br0 state UP group default
qlen 1000
link/ether c8:3a:35:da:42:72 brd ff:ff:ff:ff:ff:ff
inet 10.1.1.1/24 brd 10.1.1.255 scope global enp4s5
valid_lft forever preferred_lft forever
3: enp6s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu
1500 qdisc pfifo_fast master br0 state UP group default
qlen 1000
link/ether 70:85:c2:3b:13:24 brd ff:ff:ff:ff:ff:ff
inet [xx.xx.xx.xx]/20 brd 255.255.255.255 scope global
enp6s0
valid_lft forever preferred_lft forever
inet6 fe80::7285:c2ff:fe3b:1324/64 scope link
valid_lft forever preferred_lft forever
4: wlp2s0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu
1500 qdisc noqueue state DOWN group default qlen 1000
link/ether f0:7d:68:c1:b4:13 brd ff:ff:ff:ff:ff:ff
inet 10.1.1.10/24 brd 10.1.1.255 scope global wlp2s0
valid_lft forever preferred_lft forever
5: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500
qdisc noqueue state UP group default qlen 1000
link/ether 70:85:c2:3b:13:24 brd ff:ff:ff:ff:ff:ff
inet 10.1.1.1/24 brd 10.1.1.255 scope global br0
valid_lft forever preferred_lft forever
inet6 fe80::7285:c2ff:fe3b:1324/64 scope link
valid_lft forever preferred_lft forever
# ip route
default via 174.xx.yy.1 dev enp6s0
10.1.1.0/24 dev enp4s5 proto kernel scope link src
10.1.1.1
174.xx.yy.0/20 dev enp6s0 proto kernel scope link src
174.xx.bb.zz
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
|
|
|
It apparently defaults to /32 when one neglects to specify a
netmask.
We seem to have moved past dhcp... Take this private so as not to
bother others with non-dhcp related issues?
Many thanks to all!!! Much appreciated!!!
On 01/27/2018 06:31 PM, Bill Shirley
wrote:
Also in the entries you've shown: FOUR, SEVEN, and EIGHT are
using /32 which I think should be /24 I would think. EIGHT is a
rule for the bridge, do you need that?
Bill
On 1/27/2018 9:24 PM, Bill Shirley
wrote:
You're looking in the wrong table. You want 'iptables -t nat'.
You need an entry something like:
iptables -t nat -A POSTROUTING -o
enp6s0 -s 10.1.1.0/24 -j MASQUERADE
I don't craft my iptables by hand; I use Shorewall.
Bill
On 1/27/2018 7:52 PM, A wrote:
On 01/27/2018 04:22 PM, Bill
Shirley wrote:
I don't know if it is affecting anything but you still have
the bridge defined
in /etc/network/interfaces. Also, you still have wlp2s0 on
10.1.1.0/24. Do
you want to define the wireless?
Yes. I just finished responding to your prior email. I need
to run out for a few minutes before it gets dark. Back in 30.
So 'blue' is to use 'yellow' to get to the internet. Do you
have iptables on
'yellow' set up to masquerade for 10.1.1.0/24
This is what I have at the moment so far. I see an error with
FOUR. Back in 30.
-A PREROUTING -i enp6s0 -p tcp -m multiport --dports 80,443 -j
DNAT --to-destination 10.1.1.1
-A FORWARD -i enp6s0 -o wlp2s0 -m conntrack --ctstate
RELATED,ESTABLISHED -m comment --comment THREE -j ACCEPT
-A FORWARD -d 10.1.1.0/32 -i enp4s5 -o enp6s0 -m comment
--comment FOUR -j ACCEPT
-A FORWARD ! -d 10.1.1.0/32 -o enp6s0 -m comment --comment
SEVEN -j ACCEPT
-A FORWARD -d 10.1.1.0/32 -o br0 -m conntrack --ctstate
RELATED,ESTABLISHED -m comment --comment EIGHT -j ACCEPT
Bill
On 1/27/2018 7:10 PM, A wrote:
I meant to include the current
/etc/network/interfaces. Below. However, in the
meantime I'm getting different results. Perhaps due
to the fact that I changed "static" to "manuel". I
also deleted the bridge. Now, both machines
can ping each other on the wired interface, and
yellow can still ping the 'Net. Blue cannot ping the
Internet.
It's unclear if the bridge-utils is
truly out of the picture, despite the tools reporting
so. I suspect this may still be an issue that will
come back later when I retry.
PING blue (10.1.1.14) 56(84) bytes
of data.
64 bytes from blue (10.1.1.14): icmp_seq=1 ttl=64
time=0.353 ms
ping google.com
PING google.com (172.217.11.78) 56(84) bytes of data.
64 bytes from lax17s34-in-f14.1e100.net
(172.217.11.78): icmp_seq=1 ttl=56 time=23.4 ms
# ping yellow
PING yellow (127.0.1.1) 56(84) bytes of data.
64 bytes from yellow (127.0.1.1): icmp_seq=1 ttl=64
time=0.088 ms
^C
--- yellow ping statistics ---
1 packets transmitted, 1 received, 0% packet loss,
time 0ms
rtt min/avg/max/mdev = 0.088/0.088/0.088/0.000 ms
# ping router
PING yellow (10.1.1.1) 56(84) bytes of data.
64 bytes from yellow (10.1.1.1): icmp_seq=1 ttl=64
time=0.077 ms
^C
--- yellow ping statistics ---
1 packets transmitted, 1 received, 0% packet loss,
time 0ms
rtt min/avg/max/mdev = 0.077/0.077/0.077/0.000 ms
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~`
/etc/network/interfaces:
auto lo
iface lo inet loopback
dns-nameservers 10.1.1.1 8.8.8.8 8.8.4.4 50.23.197.95
dns-search FQDN
auto enp6s0
iface enp6s0 inet dhcp
dns-nameservers 10.1.1.1 8.8.8.8 8.8.4.4 50.23.197.95
dns-search FQDN
auto enp4s5
allow-hotplug enp4s5
iface enp4s5 inet manuel
gateway 10.1.1.1
network 10.1.1.0
netmask 255.255.255.0
broadcast 10.1.1.255
# Before we can change the address we have to bring
the face down
pre-up ip link set enp4s5 down
# I don't know if I can use two ups. I don't know the
right way to do this.
up ip address 0.0.0.0 dev enp4s5
up ip link set enp4s5 up
down ip link set enp4s5 down
allow-hotplug wlp2s0
iface wlp2s0 inet manuel
gateway 10.1.1.1
network 10.1.1.0
netmask 255.255.255.0
broadcast 10.1.1.255
# I don't know if I can use two pre-ups. I don't know the
right way to do this.
pre-up ip link set wlp2s0 down
pre-up ip address 0.0.0.0 dev wlp2s0
up ip link set wlp2s0 up
down ip link set wlp2s0 down
wireless-mode master
wireless-essid XXXXXXXXXXXXXX
wireless-channel 1
wpa-ssid XXXXXXXXXXXXXX
wpa-psk
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
gateway 10.1.1.1
auto br0
iface br0 inet static
address 10.1.1.1
network 10.1.1.0
netmask 255.255.255.0
broadcast 10.1.1.255
bridge-ports enp4s5 wlp2s0
On 01/27/2018 03:20 PM, A
wrote:
On 01/27/2018 01:28 PM,
Simon Hobson wrote:
I did
originally have two separate subnets with a /28
CIDR, but I was unable to reach the Internet
from blue and someone suggested I have one
subnet in order to act as a typical home router.
So I reconfigured everything and it's now borked
worse than it was. Said person disappeared
shortly after of course.
There is no commercial router. Yellow is the
router, gateway, access point, dhcp server, dns
server, firewall (iptables) and more.
OK, so this box is your gateway, AP, etc, etc. In
that case I believe that your setup is fundamentally
broken - you have TWO SEPARATE networks (one wired,
one wireless) running the same subnet.
Yes, that's how I was told to set it up by a helpful
individual. I was told since it was one subnet, no
routing would be needed. The wireless & wired
interfaces would be bridged. Seemed reasonable. It
sounds like you are suggesting exactly the same thing so
"fundamentally broken" seems a bit harsh.
Thus devices on the wired network cannot talk to
devices on the WiFi and vice-verca.
Bear in mind that I've not used WiFi in this
manner (I'm used to using external APs), so I am
unsure of some of the details. If you want to run a
single unified network then you will need to create
a bridge, and put the wired and wireless adapters
into that bridge - and put your address 10.1.1.1/24
onto the bridge. You will then have one network, and
the bridge software will pass packets between them,
as well as keeping track of which clients are in
which network segment.
I removed the bridge because I was unable to reach the
Internet from yellow (nor blue). And that is how things
stand now. Bridge up, Internet down. Bridge down,
Internet up.
As far as (almost) all software on your box is
concerned, you just deal with one interface (the
bridge, eg br0). What I am unsure about is how dhcpd
behaves in this case - hopefully someone who's run
this setup can comment ? I would hope that it would
use the bridge interface in the same manner as it
would use a "real" one, but there can be some subtle
differences.
I had it working with the bridge at one point - each box
could ping the other on both wired & wireless, but
blue couldn't reach the Internet. Lets see if we can
put it back.
.... blue now receives an IP of .14; neither machine can
ping the other, though each can ping its own assigned
IP.
# brctl show
bridge name bridge id STP enabled
interfaces
br0 8000.7085c23b1324 no
enp4s5
enp6s0
$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc
noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd
00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: enp4s5: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu
1500 qdisc pfifo_fast master br0 state UP group default
qlen 1000
link/ether c8:3a:35:da:42:72 brd ff:ff:ff:ff:ff:ff
inet 10.1.1.1/24 brd 10.1.1.255 scope global enp4s5
valid_lft forever preferred_lft forever
3: enp6s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu
1500 qdisc pfifo_fast master br0 state UP group default
qlen 1000
link/ether 70:85:c2:3b:13:24 brd ff:ff:ff:ff:ff:ff
inet [xx.xx.xx.xx]/20 brd 255.255.255.255 scope
global enp6s0
valid_lft forever preferred_lft forever
inet6 fe80::7285:c2ff:fe3b:1324/64 scope link
valid_lft forever preferred_lft forever
4: wlp2s0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu
1500 qdisc noqueue state DOWN group default qlen 1000
link/ether f0:7d:68:c1:b4:13 brd ff:ff:ff:ff:ff:ff
inet 10.1.1.10/24 brd 10.1.1.255 scope global wlp2s0
valid_lft forever preferred_lft forever
5: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500
qdisc noqueue state UP group default qlen 1000
link/ether 70:85:c2:3b:13:24 brd ff:ff:ff:ff:ff:ff
inet 10.1.1.1/24 brd 10.1.1.255 scope global br0
valid_lft forever preferred_lft forever
inet6 fe80::7285:c2ff:fe3b:1324/64 scope link
valid_lft forever preferred_lft forever
# ip route
default via 174.xx.yy.1 dev enp6s0
10.1.1.0/24 dev enp4s5 proto kernel scope link src
10.1.1.1
174.xx.yy.0/20 dev enp6s0 proto kernel scope link src
174.xx.bb.zz
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
|
|
|
A < [hidden email]> wrote:
> I meant to include the current /etc/network/interfaces. Below.
> auto enp4s5
> allow-hotplug enp4s5
> iface enp4s5 inet manuel
> gateway 10.1.1.1
> network 10.1.1.0
> netmask 255.255.255.0
> broadcast 10.1.1.255
>
> # Before we can change the address we have to bring the face down
> pre-up ip link set enp4s5 down
>
> # I don't know if I can use two ups. I don't know the right way to do this.
> up ip address 0.0.0.0 dev enp4s5
> up ip link set enp4s5 up
> down ip link set enp4s5 down
Where on earth has this come from, it's an extremely unusual setup. By the way, it should be manual not manuel.
> allow-hotplug wlp2s0
> iface wlp2s0 inet manuel
> gateway 10.1.1.1
> network 10.1.1.0
> netmask 255.255.255.0
> broadcast 10.1.1.255
> auto br0
> iface br0 inet static
> address 10.1.1.1
> network 10.1.1.0
> netmask 255.255.255.0
> broadcast 10.1.1.255
> bridge-ports enp4s5 wlp2s0
I would suggest trying this :
auto enp4s5
iface enp4s5 inet manual
auto wlp2s0
iface wlp2s0 inet manual
(add wifi settings here)
auto br0
iface br0 inet static
address 10.1.1.1
netmask 255.255.255.0
bridge-ports enp4s5 wlp2s0
That on it's own should give you a working setup with your wired and wireless bridged. You then use br0 for your networking. The bridge code takes care of tracking which devices are on which bridge port.
Not that there is no default gateway here - it would be pointing to itself. The default gateway will be set when you WAN interface is up and will point to your ISP's router.
However, I'm still not sure exactly how dhcpd will work in this setup as it's not a config I've used.
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
|
|
|
A < [hidden email]> wrote:
>> OK, so this box is your gateway, AP, etc, etc. In that case I believe that your setup is fundamentally broken - you have TWO SEPARATE networks (one wired, one wireless) running the same subnet.
>
> Yes, that's how I was told to set it up by a helpful individual. I was told since it was one subnet, no routing would be needed. The wireless & wired interfaces would be bridged. Seemed reasonable. It sounds like you are suggesting exactly the same thing so "fundamentally broken" seems a bit harsh.
Key thing there is BRIDGED - ONE bridge interface with ONE address in the subnet, more than one port assigned to the bridge. What you have is NOT a bridged network, it is two SEPARATE networks with the same subnet - it's is fundamentally broken and will NOT work (at least without a lot of fudging around to work around the brokenness.
> I removed the bridge because I was unable to reach the Internet from yellow (nor blue). And that is how things stand now. Bridge up, Internet down. Bridge down, Internet up.
OK, so there's a different issue there, and it'll be to do with your masq setup.
You probably need to take a step back and get the basics working first. Forget your DHCP for the moment and statically configure some clients - that way you can work on one issue at a time.
Get the internal networking going (devices can connect between wired and wireless).
Get the internet connection working - ie setup your masq rules.
THEN work on dhcp etc.
As it is, I think you are trying to troubleshoot multiple issues at once which makes it much harder - especially when, as it appears here, networking isn't you specialist subject.
BTW - you MUST also configure filters on inbound traffic, while a GNU/Linux system is fairly secure out of the box, it is likely to be running services that you don't want to expose. So configure rules that permit only the traffic inbound to the firewall that you want, and drop everything else.
I'm another that doesn't normally work direct with iptables - I use Shorewall too.
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
|
|
|
On 01/28/2018 01:38 AM, Simon Hobson
wrote:
A [hidden email] wrote:
OK, so this box is your gateway, AP, etc, etc. In that case I believe that your setup is fundamentally broken - you have TWO SEPARATE networks (one wired, one wireless) running the same subnet.
Yes, that's how I was told to set it up by a helpful individual. I was told since it was one subnet, no routing would be needed. The wireless & wired interfaces would be bridged. Seemed reasonable. It sounds like you are suggesting exactly the same thing so "fundamentally broken" seems a bit harsh.
Key thing there is BRIDGED - ONE bridge interface with ONE address in the subnet, more than one port assigned to the bridge. What you have is NOT a bridged network, it is two SEPARATE networks with the same subnet - it's is fundamentally broken and will NOT work (at least without a lot of fudging around to work around the brokenness.
I've never setup a bridge before and got the syntax for brctl wrong
and that's what caused the config you saw. I thought I was telling
it to bridge wired & wireless faces, when apparently it was
doing something else without telling me so. I was doing: brctl
addif br0 enp4s5 wlp2s0 which I thought linked the two faces. It
apparently added the enp4s5 and ignored the wlp2s0.
Once I finally realized that yesterday and corrected the syntax it
will not add the wireless interface as a port.
# brctl addif br0 wlp2s0
can't add wlp2s0 to bridge br0: Operation not supported
And just to be complete:
# brctl addif br0 enp4s5
device enp4s5 is already a member of a bridge; can't enslave it to
bridge br0.
# brctl addif br0 enp6s0
#
That one succeeds, because like 4s5, 6s0 is a wired NIC.
That's after changing "manuel" to "manual" just in case that was a
relevant issue.
Therefore as I can't add the wireless face as a port, I'm unable to
bridge using brctl from the bridge-utils package. So unless there
is another virtual bridge package, bridging won't work. Unless of
course I'm still doing it wrong which is always a possibility.
I removed the bridge because I was unable to reach the Internet from yellow (nor blue). And that is how things stand now. Bridge up, Internet down. Bridge down, Internet up.
OK, so there's a different issue there, and it'll be to do with your masq setup.
You probably need to take a step back and get the basics working first. Forget your DHCP for the moment and statically configure some clients - that way you can work on one issue at a time.
I had everything working including DHCP except blue->Internet.
After getting that far by myself, someone redirected me to a
different setup that as you've pointed out, is broken, starting with
the bridging package itself (no wireless support).
So proceeding further down this path is not possible afaik.
Therefore, also considering the fact that bridge-utils is considered
deprecated, I'm going to go back to my original setup of 2 separate
subnets and route them as I originally intended. I got sent down the
garden path, thanks for helping bring me back!
There is apparently another way to do this using systemd I stumbled
on, but I have not looked into it, bridge-utils seemed to be the
fastest way forward. Sadly, it was not.
Thank you for all your insight and help, it is greatly appreciated!
By the way... do you (or anyone) know of a general networking
mailing list? Thanks again!
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
|
|
|
It suddenly occurred to me that it's probably my wireless card
that does not support the operation, however it's ambiguous.
It's moot though because dhcpd won't listen on a virtual
interface (unless I messed something up there too!)
In any event, I was able to get both blue and yellow onto the
'Net today with Bill Shirley's help and of course everyone else
that pointed out my various mistakes.
Thanks again to everyone that participated, much appreciated!!!
On 01/28/2018 10:19 AM, A wrote:
# brctl addif br0 wlp2s0
can't add wlp2s0 to bridge br0: Operation not supported
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
|
|
|
A < [hidden email]> wrote:
> I've never setup a bridge before and got the syntax for brctl wrong and that's what caused the config you saw. I thought I was telling it to bridge wired & wireless faces, when apparently it was doing something else without telling me so. I was doing: brctl addif br0 enp4s5 wlp2s0 which I thought linked the two faces. It apparently added the enp4s5 and ignored the wlp2s0.
>
> Once I finally realized that yesterday and corrected the syntax it will not add the wireless interface as a port.
>
> # brctl addif br0 wlp2s0
> can't add wlp2s0 to bridge br0: Operation not supported
>
> ...
> That's after changing "manuel" to "manual" just in case that was a relevant issue.
>
> Therefore as I can't add the wireless face as a port, I'm unable to bridge using brctl from the bridge-utils package. So unless there is another virtual bridge package, bridging won't work. Unless of course I'm still doing it wrong which is always a possibility.
After a quick search, I came across these :
https://wiki.debian.org/BridgeNetworkConnections#Bridging_with_a_wireless_NIC> Just like you can bridge two wired ethernet interfaces, you can bridge between an ethernet interface and a wireless interface. However, most Access Points (APs) will reject frames that have a source address that didn’t authenticate with the AP ...
Note that as you are operating in access point mode, you do NOT need to do all the ebtables stuff it then carries on to describe.
And then :
https://wiki.archlinux.org/index.php/Network_bridge#Wireless_interface_on_a_bridge> To add a wireless interface to a bridge, you first have to assign the wireless interface to an access point or start an access point with hostapd. Otherwise the wireless interface will not be added to the bridge.
So this seems to imply that the wireless interface must be up and configured BEFORE it can be added to the bridge.
Next test is to make sure hostapd is running, and then see if the wireless interface can be added. Both these pages are clear that a wireless NIC can be added to a bridge.
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
|
|
|
So this seems to imply that the wireless interface must be up and configured BEFORE it can be added to the bridge.
No doubt that's another place where I went wrong. wireless face is
still not up. Had it working at one time, no longer. Thanks for
all your input Simon! I think I'm going to stick with what's
working right now (as mentioned in another email, blue & yellow
can both ping the 'Net over wired) and focus on figuring out what's
wrong with hostapd, then on to remaining DNS issues. I greatly
appreciate all your input!!!
On 01/28/2018 12:28 PM, Simon Hobson
wrote:
After a quick search, I came across these :
https://wiki.debian.org/BridgeNetworkConnections#Bridging_with_a_wireless_NIC
Just like you can bridge two wired ethernet interfaces, you can bridge between an ethernet interface and a wireless interface. However, most Access Points (APs) will reject frames that have a source address that didn�t authenticate with the AP ...
Note that as you are operating in access point mode, you do NOT need to do all the ebtables stuff it then carries on to describe.
And then :
https://wiki.archlinux.org/index.php/Network_bridge#Wireless_interface_on_a_bridge
To add a wireless interface to a bridge, you first have to assign the wireless interface to an access point or start an access point with hostapd. Otherwise the wireless interface will not be added to the bridge.
So this seems to imply that the wireless interface must be up and configured BEFORE it can be added to the bridge.
Next test is to make sure hostapd is running, and then see if the wireless interface can be added. Both these pages are clear that a wireless NIC can be added to a bridge.
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
|
12
|
Locked
