Почему виртуальная машина windows 7 pro не берет IP от DHCP pfSens?

Question

[winmasta]

Хост - MacBook Air, на нем Virtualbox 4.3.26 сеть в режиме моста, на нем Windows 7 Professional сетевое подключение берет IP автоматом, домашняя сеть WiFi роутер Asus RT-AC66U в режиме роутера, рабочая сеть WiFi D-Link DIR-300 в режиме AP, а DHCP сервер pfSense 2.2.1

суть проблемы: дома виртуалка спокойно берет IP адрес от роутера, на работе отказывается, берет из диапазона 169.254.0.0/16, при этом остальные устройства на работе (телефоны, планшеты, ноутбуки) берут адрес без проблем

в лога windows ничего не нашел

в логах pfSense:

Apr 15 14:02:38 dhcpd: DHCPOFFER on 192.168.6.203 to 08:00:27:6d:3b:10 via em2
Apr 15 14:02:38 dhcpd: DHCPDISCOVER from 08:00:27:6d:3b:10 via em2

Answer 1

[throughtheether]

Есть подозрение, что точка доступа не передает хост-машине ответ DHCP-сервера. Вы можете проверить это при помощи tcpdump на соответствующем интерфейсе. В таком случае необходимо изменить настройки AP (в Cisco-мире нужная опция называется passive client, см. подобный вопрос).

Другой вариант, ответ DHCP-сервера не доходит до ВМ из-за особенностей Virtualbox (см. релевантный топик). В этом случае можно попробовать убедить DHCP-сервер слать DHCP OFFER в широковещательном режиме.

В любом случае, в качестве паллиатива вы можете или задать статические настройки IP, или использовать NAT между ВМ и хост-машиной.

Comments

[winmasta]

посмотрел все tcpdump'ом и вот что вышло
1) запрос адреса уходит широковещательно и доходит до сервера
2) ответ уходит от сервера, но не попадает на WiFi интерфейс ноутбука

получается, что точка доступа его не передает, но всем остальным устройствам (ВМ больше нету в этой подсети), например хостовому ноутбуку, телефонам и планшетам передает, никакой настройки в точке доступа не нашел

[throughtheether]

winmasta:

1) запрос адреса уходит широковещательно и доходит до сервера

Это и так понятно, по предоставленным дампам. Вопрос был в том, какой MAC-адрес назначения у DHCP-ответа, скорее всего unicast. Но это уже не важно, см. дальше.

2) ответ уходит от сервера, но не попадает на WiFi интерфейс ноутбука

Скорее всего, дело в точке доступа.

[winmasta]

throughtheether: MAC-адрес назначения тот, с которого был отправлен запрос
а почему все-таки все остальные беспроводные клиенты получают адреса, а ВМ нет, т.е. в одном случае точка доступа передает пакеты, а в другом нет ?

[winmasta]

сдампил разницу

это телефон запросил адрес

IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from c0:ee:fb:01:e5:d6 (oui Unknown), length 314
IP 192.168.6.1.bootps > 192.168.6.201.bootpc: BOOTP/DHCP, Reply, length 300

а это ВМ запросила адрес

IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 08:00:27:03:21:ec (oui Unknown), length 300
IP 192.168.6.1.bootps > 255.255.255.255.bootpc: BOOTP/DHCP, Reply, length 300

почему-то ответ широковещательный

[winmasta]

более verbose

с телефона

IP (tos 0x0, ttl 64, id 63895, offset 0, flags [none], proto UDP (17), length 342)
0.0.0.0.bootpc > 255.255.255.255.bootps: [udp sum ok] BOOTP/DHCP, Request from c0:ee:fb:01:e5:d6 (oui Unknown), length 314, xid 0x3b00bcaf, Flags [none] (0x0000)
Client-Ethernet-Address c0:ee:fb:01:e5:d6 (oui Unknown)
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: Request
Client-ID Option 61, length 7: ether c0:ee:fb:01:e5:d6
Requested-IP Option 50, length 4: 192.168.6.201
MSZ Option 57, length 2: 1500
Vendor-Class Option 60, length 12: "dhcpcd-5.5.6"
Hostname Option 12, length 23: "android-be3cffd46583c25"
Parameter-Request Option 55, length 10:
Subnet-Mask, Static-Route, Default-Gateway, Domain-Name-Server
Domain-Name, MTU, BR, Lease-Time
RN, RB
END Option 255, length 0
IP (tos 0x10, ttl 128, id 0, offset 0, flags [none], proto UDP (17), length 328)
192.168.6.1.bootps > 192.168.6.201.bootpc: [udp sum ok] BOOTP/DHCP, Reply, length 300, xid 0x3b00bcaf, Flags [none] (0x0000)
Your-IP 192.168.6.201
Client-Ethernet-Address c0:ee:fb:01:e5:d6 (oui Unknown)
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: ACK
Server-ID Option 54, length 4: 192.168.6.1
Lease-Time Option 51, length 4: 7200
Subnet-Mask Option 1, length 4: 255.255.255.0
Default-Gateway Option 3, length 4: 192.168.6.1
Domain-Name-Server Option 6, length 8: 192.168.3.1,192.168.1.150
Domain-Name Option 15, length 10: "kireva.com"
END Option 255, length 0
PAD Option 0, length 0, occurs 10

с ВМ

IP (tos 0x0, ttl 128, id 0, offset 0, flags [none], proto UDP (17), length 328)
0.0.0.0.bootpc > 255.255.255.255.bootps: [udp sum ok] BOOTP/DHCP, Request from 08:00:27:03:21:ec (oui Unknown), length 300, xid 0x9560e7af, Flags [Broadcast] (0x8000)
Client-Ethernet-Address 08:00:27:03:21:ec (oui Unknown)
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: Discover
Client-ID Option 61, length 7: ether 08:00:27:03:21:ec
Hostname Option 12, length 12: "winmasta-mac"
Vendor-Class Option 60, length 8: "MSFT 5.0"
Parameter-Request Option 55, length 12:
Subnet-Mask, Domain-Name, Default-Gateway, Domain-Name-Server
Netbios-Name-Server, Netbios-Node, Netbios-Scope, Router-Discovery
Static-Route, Classless-Static-Route, Classless-Static-Route-Microsoft, Vendor-Option
END Option 255, length 0
PAD Option 0, length 0, occurs 9
IP (tos 0x10, ttl 128, id 0, offset 0, flags [none], proto UDP (17), length 328)
192.168.6.1.bootps > 255.255.255.255.bootpc: [udp sum ok] BOOTP/DHCP, Reply, length 300, xid 0x9560e7af, Flags [Broadcast] (0x8000)
Your-IP 192.168.6.203
Client-Ethernet-Address 08:00:27:03:21:ec (oui Unknown)
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: Offer
Server-ID Option 54, length 4: 192.168.6.1
Lease-Time Option 51, length 4: 7200
Subnet-Mask Option 1, length 4: 255.255.255.0
Domain-Name Option 15, length 10: "kireva.com"
Default-Gateway Option 3, length 4: 192.168.6.1
Domain-Name-Server Option 6, length 8: 192.168.3.1,192.168.1.150
END Option 255, length 0
PAD Option 0, length 0, occurs 10

[throughtheether]

winmasta:

сдампил разницу

В ваших дампах я не увидел, какой MAC-адрес используется в именно L2-инкапсуляции. По-моему, за отображение этой информации отвечает опция '-e' утилиты tcpdump.

а почему все-таки все остальные беспроводные клиенты получают адреса, а ВМ нет, т.е. в одном случае точка доступа передает пакеты, а в другом нет ?

Чтобы детально ответить на этот вопрос применительно к ситуации, необходимо наблюдать, что происходит в эфире (в т.ч. ассоциации на точки доступа), но в общих чертах, как я понял, не каждая точка доступа позволяет ассоциированному клиенту посылать фреймы с различными MAC-адресами источника. Все 'нормальные' клиенты посылают фреймы только со своим адресом в поле адреса источника в L2-фрейме. Беспроводной интерфейс вашего Macbook, полагаю, шлет фреймы как от своего адреса, таки от адреса виртуальной машины.

Answer 2

[Антон Нагаец]

Как вариант проверить тип подключения сетевого адаптера. Должен быть в режиме Bridge ( Сетевой мост) на основную сетевую карту.

Comments

[winmasta]

так и есть

Answer 3

[dvserg]

Вот здесь решилось установкой обновлений через Windows Update.