|
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 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