|
4 | 4 | ####> are applicable to all of those.
|
5 | 5 | #### **--user-mode-networking**
|
6 | 6 |
|
7 |
| -Indicates that this machine relays traffic from the guest through a user-space |
8 |
| -process running on the host. In some VPN configurations the VPN may drop |
9 |
| -traffic from alternate network interfaces, including VM network devices. By |
10 |
| -enabling user-mode networking (a setting of `true`), VPNs observe all |
11 |
| -podman machine traffic as coming from the host, bypassing the problem. |
| 7 | +This option can only be used for the WSL provider on Windows. On all other |
| 8 | +platforms this option is ignored and user mode networking will be always be |
| 9 | +`true` there because these providers always depend on gvproxy (our user |
| 10 | +mode networking tool for the VMs) |
12 | 11 |
|
13 |
| -When the qemu backend is used (Linux, Mac), user-mode networking is |
14 |
| -mandatory and the only allowed value is `true`. In contrast, The Windows/WSL |
15 |
| -backend defaults to `false`, and follows the standard WSL network setup. |
| 12 | +In contrast, The Windows/WSL backend defaults to `false`, and follows the |
| 13 | +standard WSL network setup. |
16 | 14 | Changing this setting to `true` on Windows/WSL informs Podman to replace
|
17 | 15 | the WSL networking setup on start of this machine instance with a user-mode
|
18 | 16 | networking distribution. Since WSL shares the same kernel across
|
19 | 17 | distributions, all other running distributions reuses this network.
|
20 | 18 | Likewise, when the last machine instance with a `true` setting stops, the
|
21 | 19 | original networking setup is restored.
|
| 20 | + |
| 21 | +In some VPN configurations the VPN may drop traffic from alternate network |
| 22 | +interfaces, including VM network devices. By enabling user-mode networking |
| 23 | +VPNs observe all podman machine traffic as coming from the host, bypassing |
| 24 | +the problem. |
0 commit comments