Pfsense openvpn bridge mode not connecting to LAN
I am using openvpn configured as Bridge mode. The vpn connects successfully but cannot communicate with my lan systems. When i rectified the client tap adapter didn't get the ip address. where my lan dhcp server is working fine. also tried to assign static ip to my client tap adapter then also i cannot communicate with my lan.
"I am using openvpn configured as Bridge mode. "
Why is tun mode not viable for you? That is the better setup..
I need to disable the windows firewall to get in to the network. and I have a qnap device with sharing enabled. which not accessible by tun mode.
Huh?? Nonsense.. You sure an the hell do not need to disable the windows firewall. You just need to allow your tunnel network. As to your qnap device.. So your saying your qnap has no gateway and can only talk to devices on its own network?
If that is the case you could always source nat your vpn traffic so your qnap thinks the traffic is from same network, you could do the same with your windows firewall issue as well.
There was a recent thread where I went over source natting the vpn connection to connect to stuff that could not set a gateway.
edit: here is the thread where I went over how to source nat your vpn clients into your lan segment.
Thank you John once again fixed my problem
Fixed or worked around.. They are completely different ;)
Source natting would not be a fix to me.. That would be a work around. To me the proper fix for your issues would be correctly setting the firewall rules on your devices to accept the traffic you want to accept. Or make the choice that devices on network X behind pfsense do not need a software firewall because they trust all the devices on their same network, and devices that are hostile or not trusted are firewall at pfsense.
To a nas. it should have a gateway set if that was your issue. Or if firewall - same thing goes. Tricking something into thinking a connection is from the same local lan as it to get around firewall rules and or lack of gateway is a work around if you ask me.
Either way glad I could be of help, but if you went the source nat method. I would would evaluate if that is the best long term fix vs stop gap workaround until proper setup can be used, etc.