It depends on the type of VPN technology used and if IPSec is used for authentication and encryption and then what type of encryption and data integrity you use with IPSec. I know AH can bypass NATs and ESP can't.
But when you say modem bridged to router with VPN, are you referring to a single device with a "modem"/WAN interface and LAN (or LAN and WLAN interfaces)? Or two separate devices?
Either way, I'm assuming your modem provides you with only a single or a hand full of IPs, correct? So likely that "bridge" is a NAT interface itself. Unless by modem you mean a BGP router on the edge of an AS or an IS-IS router and you have an entire block of IPs.
If you do a traceroute to an external address (like google.com, not to your external IP), what does the output look like?
Did you configure routing tables between the modem and the router with the VPN or set up advanced routing protocols between them? Likely no, plus it would be highly uncommon to route a public IP internally prior to broadcasting it to your ISP.
So that means you have a TRIPLE NAT. Once again it goes back to the tech used for encapsulation, authentication and encryption, but let's assume you just seek encapsulation and data integrity and encryption are not factors. Let's also assume you use very basic authentication and encapsulation with raw ethernet headers exposed.
-FOR A GROUP VPN
Then the packet would flow from the connecting client to a public IP, upon reaching the modem, assuming the incoming port was correctly or automatically forwarded, it would reach the instance of openVPN server on the first router, it would be given an IP on the first NATed network. From there, the encapsulation would be stripped and it would be translated into another address by the next NAT and then again before it could reach a client. Likely it would never make it that far, because between the encapsulation being stripped and the translation by the 2 following NATs, by the time it reached the client, it would appear to be a standard packet originating from an upstream NATed network. So the client would send a reply back, only to get no response. That's because through all those NATs, it would be most likely that after passing through the following NATs, the first NAT (that reencapsulates the packet and converts it back to your public IP would likely have lost track of the connection and the other recipient in the conversation. Remember, a NAT only keeps track of originating IP and the ports for the conversation, so when it passes through a second NAT, that second NAT now only knows it's intermediate address and port mapped to that address.
It may work with a single client, and no other internet traffic, but you're likely to have a lot of dropped packets.
-FOR A POINT-TO-POINT TUNNEL
You'd have more luck here, but still the same issues would be prevalent. Double or Tripple NATing except when used in carrier grade NATs is never a good practice.
Your much better off using a managed switch if you need to segregate subnets and do it by VLAN or using a network appliance like a Sonicwall to handle both security and the VPN.
If you MUST use this config, I would see up the tunnel end point on the client you wish to access through the VPN, rather than the first NATed network router/gateway. I'd also recommend using SSLVPN over anything else, since consumer grade and lower end enterprise NAT devices generally keep track of HTTP/HTTPS traffic better, and there's no need to play around with insecure protocols that work with NATs.
