Re: vio(4) tap(4) question
On Mon, Aug 28, 2017 at 09:35:52PM -0400, Bryan Harris wrote:
> Somehow this thread gave me the idea to try:
>
> pass on { vether* tap* }
>
> Which did not work. But it lead to the idea to use the group names:
>
> pass on { vether tap }
>
> Which does work. It's funny because I like using group names (like
> egress) and I noticed earlier today that all taps are in a group
> called tap, but I never connected the dots.
>
> V/r,
> Bryan
>
Thanks, glad to see you got it working.
-ml
> On Mon, Aug 28, 2017 at 6:52 PM, Mike Larkin wrote:
> > On Mon, Aug 28, 2017 at 06:48:20PM -0400, Bryan Harris wrote:
> >> On Mon, Aug 28, 2017 at 6:18 PM, Mike Larkin wrote:
> >> > On Mon, Aug 28, 2017 at 06:03:16PM -0400, Bryan Harris wrote:
> >>
> >> >> If the vio is connected to the virtual switch, and the switch is
> >> >
> >> > But the vio(4) interface isn't visible to the host. So what you said
> >> > there
> >> > doesn't make sense. It's connected to the switch *via* the corresponding
> >> > tap interface on the host.
> >>
> >> I think I understand now.
> >>
> >> >> pass on { vether0 tap0 tap1 tap2 tap3 tap4 tap5 tap6 tap7 tap8 tap9 }
> >> >
> >> > what about just:
> >> >
> >> > pass
> >>
> >> Does that allow traffic to come in on the egress? I want to have
> >> normal traffic rules that are "more safe than nothing" during the
> >> learning process. But I also want to pass the VM traffic so that I
> >> can experiment with things in the VM without the worry that I made a
> >> pf.conf mistake.
> >>
> >> ssh_nets="{ }"
> >> vm_if = "vether0"
> >> vm_net = $vm_if:network
> >>
> >> block all
> >> set skip on lo
> >> antispoof for egress
> >> antispoof for $vm_if
> >> match in all scrub (no-df max-mss 1440)
> >>
> >> # match in log (matches) on $vm_if from $vm_net tag localnet
> >> # match log (matches) inet proto tcp from any to egress:0 port 53 tag dns
> >> # match log (matches) inet proto udp from any to egress:0 port 53 tag dns
> >>
> >> pass inet proto icmp icmp-type { echoreq, unreach }
> >> pass in on egress inet proto tcp from $ssh_nets to egress:0 port 22
> >> pass in on egress inet proto udp from any to egress:0 port 53
> >> pass in on egress inet proto tcp from any to egress:0 port { 53 80 443 }
> >> # pass in on egress proto tcp from any to egress port 80 rdr-to
> >> 192.0.2.12 port 80
> >> # pass in on egress proto tcp from any to egress port 443 rdr-to
> >> 192.0.2.12 port 443
> >>
> >> pass on { vether0 tap0 tap1 tap2 tap3 tap4 tap5 tap6 tap7 tap8 tap9 }
> >>
> >> pass out all
> >>
> >> match out on egress inet from $vm_net nat-to (egress)
> >>
> >> V/r,
> >> Bryan
> >>
> >
> > Your pf config is more complex than mine. Perhaps someone with more pf
> > expertise can comment. Mine is pretty basic, just has a rule for the NAT
> > for the VM traffic and a few other unrelated rules.
> >
> > -ml
Re: vio(4) tap(4) question
Hi Trond,
We must have been typing at the same time, yes that ended up working.
I tried a * character first but that didn't work (and wasn't in the
man page anyway).
V/r,
Bryan
On Mon, Aug 28, 2017 at 9:32 PM, trondd wrote:
> On Mon, August 28, 2017 6:03 pm, Bryan Harris wrote:
>>
>> pass on { vether0 tap0 tap1 tap2 tap3 tap4 tap5 tap6 tap7 tap8 tap9 }
>>
>> Thanks all.
>>
>> V/r,
>> Bryan
>>
>
> Can't you just use the interface group 'tap'?
>
> pass on { vether0 tap }
>
Re: vio(4) tap(4) question
Somehow this thread gave me the idea to try:
pass on { vether* tap* }
Which did not work. But it lead to the idea to use the group names:
pass on { vether tap }
Which does work. It's funny because I like using group names (like
egress) and I noticed earlier today that all taps are in a group
called tap, but I never connected the dots.
V/r,
Bryan
On Mon, Aug 28, 2017 at 6:52 PM, Mike Larkin wrote:
> On Mon, Aug 28, 2017 at 06:48:20PM -0400, Bryan Harris wrote:
>> On Mon, Aug 28, 2017 at 6:18 PM, Mike Larkin wrote:
>> > On Mon, Aug 28, 2017 at 06:03:16PM -0400, Bryan Harris wrote:
>>
>> >> If the vio is connected to the virtual switch, and the switch is
>> >
>> > But the vio(4) interface isn't visible to the host. So what you said there
>> > doesn't make sense. It's connected to the switch *via* the corresponding
>> > tap interface on the host.
>>
>> I think I understand now.
>>
>> >> pass on { vether0 tap0 tap1 tap2 tap3 tap4 tap5 tap6 tap7 tap8 tap9 }
>> >
>> > what about just:
>> >
>> > pass
>>
>> Does that allow traffic to come in on the egress? I want to have
>> normal traffic rules that are "more safe than nothing" during the
>> learning process. But I also want to pass the VM traffic so that I
>> can experiment with things in the VM without the worry that I made a
>> pf.conf mistake.
>>
>> ssh_nets="{ }"
>> vm_if = "vether0"
>> vm_net = $vm_if:network
>>
>> block all
>> set skip on lo
>> antispoof for egress
>> antispoof for $vm_if
>> match in all scrub (no-df max-mss 1440)
>>
>> # match in log (matches) on $vm_if from $vm_net tag localnet
>> # match log (matches) inet proto tcp from any to egress:0 port 53 tag dns
>> # match log (matches) inet proto udp from any to egress:0 port 53 tag dns
>>
>> pass inet proto icmp icmp-type { echoreq, unreach }
>> pass in on egress inet proto tcp from $ssh_nets to egress:0 port 22
>> pass in on egress inet proto udp from any to egress:0 port 53
>> pass in on egress inet proto tcp from any to egress:0 port { 53 80 443 }
>> # pass in on egress proto tcp from any to egress port 80 rdr-to
>> 192.0.2.12 port 80
>> # pass in on egress proto tcp from any to egress port 443 rdr-to
>> 192.0.2.12 port 443
>>
>> pass on { vether0 tap0 tap1 tap2 tap3 tap4 tap5 tap6 tap7 tap8 tap9 }
>>
>> pass out all
>>
>> match out on egress inet from $vm_net nat-to (egress)
>>
>> V/r,
>> Bryan
>>
>
> Your pf config is more complex than mine. Perhaps someone with more pf
> expertise can comment. Mine is pretty basic, just has a rule for the NAT
> for the VM traffic and a few other unrelated rules.
>
> -ml
Re: vio(4) tap(4) question
On Mon, August 28, 2017 6:03 pm, Bryan Harris wrote:
>
> pass on { vether0 tap0 tap1 tap2 tap3 tap4 tap5 tap6 tap7 tap8 tap9 }
>
> Thanks all.
>
> V/r,
> Bryan
>
Can't you just use the interface group 'tap'?
pass on { vether0 tap }
Re: vio(4) tap(4) question
On Mon, Aug 28, 2017 at 06:48:20PM -0400, Bryan Harris wrote:
> On Mon, Aug 28, 2017 at 6:18 PM, Mike Larkin wrote:
> > On Mon, Aug 28, 2017 at 06:03:16PM -0400, Bryan Harris wrote:
>
> >> If the vio is connected to the virtual switch, and the switch is
> >
> > But the vio(4) interface isn't visible to the host. So what you said there
> > doesn't make sense. It's connected to the switch *via* the corresponding
> > tap interface on the host.
>
> I think I understand now.
>
> >> pass on { vether0 tap0 tap1 tap2 tap3 tap4 tap5 tap6 tap7 tap8 tap9 }
> >
> > what about just:
> >
> > pass
>
> Does that allow traffic to come in on the egress? I want to have
> normal traffic rules that are "more safe than nothing" during the
> learning process. But I also want to pass the VM traffic so that I
> can experiment with things in the VM without the worry that I made a
> pf.conf mistake.
>
> ssh_nets="{ }"
> vm_if = "vether0"
> vm_net = $vm_if:network
>
> block all
> set skip on lo
> antispoof for egress
> antispoof for $vm_if
> match in all scrub (no-df max-mss 1440)
>
> # match in log (matches) on $vm_if from $vm_net tag localnet
> # match log (matches) inet proto tcp from any to egress:0 port 53 tag dns
> # match log (matches) inet proto udp from any to egress:0 port 53 tag dns
>
> pass inet proto icmp icmp-type { echoreq, unreach }
> pass in on egress inet proto tcp from $ssh_nets to egress:0 port 22
> pass in on egress inet proto udp from any to egress:0 port 53
> pass in on egress inet proto tcp from any to egress:0 port { 53 80 443 }
> # pass in on egress proto tcp from any to egress port 80 rdr-to
> 192.0.2.12 port 80
> # pass in on egress proto tcp from any to egress port 443 rdr-to
> 192.0.2.12 port 443
>
> pass on { vether0 tap0 tap1 tap2 tap3 tap4 tap5 tap6 tap7 tap8 tap9 }
>
> pass out all
>
> match out on egress inet from $vm_net nat-to (egress)
>
> V/r,
> Bryan
>
Your pf config is more complex than mine. Perhaps someone with more pf
expertise can comment. Mine is pretty basic, just has a rule for the NAT
for the VM traffic and a few other unrelated rules.
-ml
Re: vio(4) tap(4) question
On Mon, Aug 28, 2017 at 6:18 PM, Mike Larkin wrote:
> On Mon, Aug 28, 2017 at 06:03:16PM -0400, Bryan Harris wrote:
>> If the vio is connected to the virtual switch, and the switch is
>
> But the vio(4) interface isn't visible to the host. So what you said there
> doesn't make sense. It's connected to the switch *via* the corresponding
> tap interface on the host.
I think I understand now.
>> pass on { vether0 tap0 tap1 tap2 tap3 tap4 tap5 tap6 tap7 tap8 tap9 }
>
> what about just:
>
> pass
Does that allow traffic to come in on the egress? I want to have
normal traffic rules that are "more safe than nothing" during the
learning process. But I also want to pass the VM traffic so that I
can experiment with things in the VM without the worry that I made a
pf.conf mistake.
ssh_nets="{ }"
vm_if = "vether0"
vm_net = $vm_if:network
block all
set skip on lo
antispoof for egress
antispoof for $vm_if
match in all scrub (no-df max-mss 1440)
# match in log (matches) on $vm_if from $vm_net tag localnet
# match log (matches) inet proto tcp from any to egress:0 port 53 tag dns
# match log (matches) inet proto udp from any to egress:0 port 53 tag dns
pass inet proto icmp icmp-type { echoreq, unreach }
pass in on egress inet proto tcp from $ssh_nets to egress:0 port 22
pass in on egress inet proto udp from any to egress:0 port 53
pass in on egress inet proto tcp from any to egress:0 port { 53 80 443 }
# pass in on egress proto tcp from any to egress port 80 rdr-to
192.0.2.12 port 80
# pass in on egress proto tcp from any to egress port 443 rdr-to
192.0.2.12 port 443
pass on { vether0 tap0 tap1 tap2 tap3 tap4 tap5 tap6 tap7 tap8 tap9 }
pass out all
match out on egress inet from $vm_net nat-to (egress)
V/r,
Bryan
Re: vio(4) tap(4) question
On Mon, Aug 28, 2017 at 06:03:16PM -0400, Bryan Harris wrote:
> Hi folks,
>
> I am in the learning process about vmd. When I read the vmctl(8) man
> page I have incorrectly got the idea that I can have a VM that has a
> vio interface but without a mapping to a host tap interface, simply by
> omitting the -i option from the "vmctl start vmX" command. However,
> if I read carefully the vm.conf(5) man page I see that there is no way
> to create any VM vio which does not map to a host tap.
>
Yes, because this is the way in which traffic is supplied to the guest VM.
> >From vmctl(8) page:
>
> If the -i option is specified during VM startup, a corresponding number
> of host-side tap(4) interfaces will be allocated and mapped to the vio(4)
> interfaces inside the guest VM.
>
> >From vm.conf(5) page:
>
> Network interface to add to the VM. The optional name can be
> either `tap' to select the next available tap(4) interface on the
> VM host side (the default) or tapN to select a specific one.
>
> Hopefully I am reading properly. There is no such way to have a VM
> vio without a mapping to the host tap. Is there any future idea to
> have a vio inside the VM which does not connect to the tap on the
> host?
>
> If the vio is connected to the virtual switch, and the switch is
But the vio(4) interface isn't visible to the host. So what you said there
doesn't make sense. It's connected to the switch *via* the corresponding
tap interface on the host.
> connected to vether0, and the vether0 is on the host, and the host has
> forwarding=1, then I thought it might be possible.
>
> Here is my purpose in asking about all this. Every time I create a VM
> I have to put stuff in the host pf.conf in order to pass the traffic,
> and I have had a hard time using any rule except one like below. Is
> there any way to pass all VM vio<->host tap traffic, or is there a way
> to bypass this need to change the pf rules each time?
>
> pass on { vether0 tap0 tap1 tap2 tap3 tap4 tap5 tap6 tap7 tap8 tap9 }
what about just:
pass
???
> Thanks all.
>
> V/r,
> Bryan
>
vio(4) tap(4) question
Hi folks,
I am in the learning process about vmd. When I read the vmctl(8) man
page I have incorrectly got the idea that I can have a VM that has a
vio interface but without a mapping to a host tap interface, simply by
omitting the -i option from the "vmctl start vmX" command. However,
if I read carefully the vm.conf(5) man page I see that there is no way
to create any VM vio which does not map to a host tap.
>From vmctl(8) page:
If the -i option is specified during VM startup, a corresponding number
of host-side tap(4) interfaces will be allocated and mapped to the vio(4)
interfaces inside the guest VM.
>From vm.conf(5) page:
Network interface to add to the VM. The optional name can be
either `tap' to select the next available tap(4) interface on the
VM host side (the default) or tapN to select a specific one.
Hopefully I am reading properly. There is no such way to have a VM
vio without a mapping to the host tap. Is there any future idea to
have a vio inside the VM which does not connect to the tap on the
host?
If the vio is connected to the virtual switch, and the switch is
connected to vether0, and the vether0 is on the host, and the host has
forwarding=1, then I thought it might be possible.
Here is my purpose in asking about all this. Every time I create a VM
I have to put stuff in the host pf.conf in order to pass the traffic,
and I have had a hard time using any rule except one like below. Is
there any way to pass all VM vio<->host tap traffic, or is there a way
to bypass this need to change the pf rules each time?
pass on { vether0 tap0 tap1 tap2 tap3 tap4 tap5 tap6 tap7 tap8 tap9 }
Thanks all.
V/r,
Bryan
