When an isolated port transmits data, that data is mapped into an auxiliary VLAN. Data in the auxiliary VLAN will be mapped to the primary VLAN -only- for transmission to promiscuous ports. Promiscuous ports, in turn, transmit data into the primary VLAN. All ports can receive information in the primary VLAN.
Putting an otherwise isolated port into a community VLAN means that traffic it transmits will be mapped into both the auxiliary and the community VLAN. Community ports will receive data from both the primary and the community VLAN.
A given pair of ports will have bidirectional communication under the following conditions-
- One or both are promiscuous, or...
- Both are in the same PVLAN community.
VACL's are a completely different mechanism and provide some measure of per-packet (and usually protocol based) control of traffic bridged within a given VLAN. You might, for instance, block traffic on TCP/80 between all hosts within the VLAN while allowing all other traffic to pass.
It's possible to approximate the effects of PVLAN's by using a VACL but this tends to be somewhat fragile, difficult to manage and there are often inherent hardware limitations with which to contend (...highly dependent on platform).
It kind of depends on how much data you will be moving between these two external subnets. If you allow the HP to route directly between those subnets, you can have as many 1GB streams between them as you have ports configured for them. With "router-on-a-stick" (I've always called it vlan-on-a-stick, but same concept), you would be limited to just 1GB in total throughput between the vlans (leaving out the possibility of doing an lacp trunk between the SonicWALL and the HP).
In doing this method, the third vlan would be considered a "transit network", and would make it easier down the road as your network grows to implement a dynamic routing protocol, or to add more routers into the network, if the need ever arises.
The HP switch would be acting as your layer 3 core, and you would have an IP address in each of the 3 vlans. The SonicWALL would need only an access port to the transit network, and it's own IP on that network.
From there, a default route statement in the HP pointing to the SonicWALL's transit net ip address, and two static routes in the SonicWALL (one for each of your 'external' subnets) pointing back at the HP's transit net IP.
The easy button is to simply run a vlan trunk to the SonicWALL, and put an address on each of the vlans you want to route for. I've done it this way in the past, and if you don't plan on heavy traffic, it's perfectly viable, and pretty easy to configure.
If you could post some of your route statements in your attempts at setting up the transit net, I'm sure someone could help you get that straightened out.
Best Answer
If you want to remove the "barrier" between the VLANs just reconfigure the ports to use the same VLAN ID.
As Ron's pointed out, a router is required to enable communication between two VLANs (=distinct L2 segments). In your case that isn't possible as both VLANs use the same IP subnet - you'd need to renumber one of the subnets (or use a highly awkward source and destination NAT).
Routing doesn't work with identical (or overlapping) subnets because a sending node consults its local routing table, finds that the destination is on the local subnet and tries to ARP the destination IP address. Failing that (since the destination is in another broadcast domain), transmission fails altogether. Static ARP entries won't help either as distinct VLANs do not communicate directly, ie. on the L2.