I don't have SUP7 to test, but it works on SUP6 and SUP32, I would presume SUP7 retains this functionality.
I've tested between JNPR M320 <-> SUP32, and 'vlan mapping JNPR SUP32' works just fine.
There is no need for QinQ, what the QinQ option does is it adds top tag to one particularly tag. So switchport vlan mapping 1042 dot1q-tunnel 42
would map incoming [1042] stack to [42 1042] stack.
As opposed to switchport vlan mapping 1042 42
which maps incoming dot1q Vlan [1042] to dot1q Vlan [42].
JNPR M320 config:
{master}[edit interfaces ge-0/1/0 unit 1042]
user@m320# show
vlan-id 1042;
family inet {
address 10.42.42.1/24;
}
{master}[edit interfaces ge-0/1/0 unit 1042]
user@m320# run show interfaces ge-0/1/0
Physical interface: ge-0/1/0, Enabled, Physical link is Up
Interface index: 135, SNMP ifIndex: 506
Description: B: SUP32 ge5/1
Link-level type: Flexible-Ethernet, MTU: 9192, Speed: 1000mbps, BPDU Error: None,
MAC-REWRITE Error: None, Loopback: Disabled, Source filtering: Disabled, Flow control: Disabled,
Auto-negotiation: Enabled, Remote fault: Online
Device flags : Present Running
Interface flags: SNMP-Traps Internal: 0x4000
CoS queues : 8 supported, 8 maximum usable queues
Current address: 00:12:1e:d5:90:7f, Hardware address: 00:12:1e:d5:90:7f
Last flapped : 2013-02-19 09:14:29 UTC (19w6d 21:12 ago)
Input rate : 4560 bps (5 pps)
Output rate : 6968 bps (4 pps)
Active alarms : None
Active defects : None
Interface transmit statistics: Disabled
SUP32 config:
SUP32#show run int giga5/1
Building configuration...
Current configuration : 365 bytes
!
interface GigabitEthernet5/1
description F: M320 ge-0/1/0
switchport
switchport trunk encapsulation dot1q
switchport mode trunk
switchport nonegotiate
switchport vlan mapping enable
switchport vlan mapping 1042 42
mtu 9216
bandwidth 1000000
speed nonegotiate
no cdp enable
spanning-tree portfast edge trunk
spanning-tree bpdufilter enable
end
SUP32#show ru int vlan42
Building configuration...
Current configuration : 61 bytes
!
interface Vlan42
ip address 10.42.42.2 255.255.255.0
end
SUP32#sh int GigabitEthernet5/1 vlan mapping
State: enabled
Original VLAN Translated VLAN
------------- ---------------
1042 42
SUP32#sh int vlan42
Vlan42 is up, line protocol is up
Hardware is EtherSVI, address is 0005.ddee.6000 (bia 0005.ddee.6000)
Internet address is 10.42.42.2/24
MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA, loopback not set
Keepalive not supported
ARP type: ARPA, ARP Timeout 04:00:00
Last input 00:00:09, output 00:01:27, output hang never
Last clearing of "show interface" counters never
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue: 0/40 (size/max)
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
L2 Switched: ucast: 17 pkt, 1920 bytes - mcast: 0 pkt, 0 bytes
L3 in Switched: ucast: 0 pkt, 0 bytes - mcast: 0 pkt, 0 bytes mcast
L3 out Switched: ucast: 0 pkt, 0 bytes mcast: 0 pkt, 0 bytes
38 packets input, 3432 bytes, 0 no buffer
Received 21 broadcasts (0 IP multicasts)
0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
26 packets output, 2420 bytes, 0 underruns
0 output errors, 0 interface resets
0 output buffer failures, 0 output buffers swapped out
And
SUP32#ping 10.42.42.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.42.42.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms
SUP32#sh arp | i 10.42.42.1
Internet 10.42.42.1 12 0012.1ed5.907f ARPA Vlan42
SUP32#show mac address-table dynamic address 0012.1ed5.907f
Legend: * - primary entry
age - seconds since last seen
n/a - not available
vlan mac address type learn age ports
------+----------------+--------+-----+----------+--------------------------
Active Supervisor:
* 450 0012.1ed5.907f dynamic Yes 0 Gi5/1
* 50 0012.1ed5.907f dynamic Yes 0 Gi5/1
* 40 0012.1ed5.907f dynamic Yes 0 Gi5/1
* 42 0012.1ed5.907f dynamic Yes 5 Gi5/1
user@m320# run ping 10.42.42.2 count 2
PING 10.42.42.2 (10.42.42.2): 56 data bytes
64 bytes from 10.42.42.2: icmp_seq=0 ttl=255 time=0.495 ms
64 bytes from 10.42.42.2: icmp_seq=1 ttl=255 time=0.651 ms
--- 10.42.42.2 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max/stddev = 0.495/0.573/0.651/0.078 ms
{master}[edit interfaces ge-0/1/0 unit 1042]
user@m320# run show arp no-resolve |match 10.42.42.2
00:05:dd:ee:60:00 10.42.42.2 ge-0/1/0.1042 none
I've run into this problem before and there's a couple things happening in this scenario.
First, The Management interface does not play by the same rules as other interfaces on the FW. By default it will not pass or receive traffic from any other interface on the device due to the "Management-Only" setting.
Second, the way that Cisco implements the Management interface causes a routing loop with the ASA. You would like to route all traffic to the management network through the L3 switch on the Inside, but the ASA sees the Management network as directly connected via the Management interface
You would like the traffic to take the following path:
IPS > L3 Switch > ASA Inside > Internet > ASA Outside > L3 Switch > IPS
Unfortunately, the path it is actually taking looks like this:
IPS > L3 Switch > ASA Inside > Internet > ASA Outside > Bit Bucket
Any packet sent from the IPS to the internet is returned to the ASA Outside interface, at which point the routing table is checked and it sees that the management network is directly connected via the Management interface. Since the Management interface will not receive traffic from another interface by default, the bits hit the floor.
Unfortunately, the best way to resolve this issue is to abandon using the Management interface to manage the firewall and instead use the Inside interface. If you remove the IP address of the Management interface (but still keep the port enabled for the IPS module), that will remove the Management network from the ASA routing table. This will allow the traffic to take the correct path back to the L3 switch on the Inside when it returns from the Internet.
I hope this helps
Best Answer
You have a few options, two of which in particular come to mine.
Solution 1
Many times, when a Vendor says "no NAT is allowed", they really mean "no PAT is allowed". This is typically because of a PAT being, by definition, unidirectional. In most VPN type systems, both peers need to be able to initiate traffic to the other, which isn't possible in a unidirectional communication system, like PAT.
As such, the solution is to give your Checkpoint Firewall a Private address, say 192.168.1.25. Then create a Static NAT on your ASA to translate 192.168.1.25 to one of the IPs in the additional /30 your ISP has assigned.
From the VPN configuration perspective, the remote end will use the Public /30 address as their "opposing peer", and you will use the other end's IP address as your "opposing peer". Then, as long as NAT Traversal is enabled (which it typically is by default, but I can only confirm that on the Cisco ASA), the VPN tunnel should be able to build through the Static NAT.
This is your ideal solution, I would suggest going this route if you can. Mainly, because you are holding in reserve the other 3 IPs of the 4 they gave you in the /30. But, if you see no use for these, now or in the future, Solution 2 might work out for you:
Solution 2
Use the /30 assigned by your ISP as its own "transit" network between the ASA and Checkpoint. You'll need an additional interface on the ASA, or you could have the same effect with a Trunk configuration. The ASA will have two segments off it, the transit network, and the DMZ network. Then your "inside" network will simply be "behind" the Checkpoint.
I was going to try to explain this with text, but I figured a picture was easier. I made up the IPs, since you didn't provide them:
You could either use Identity NAT on the ASA to allow the traffic through un-natted, or simply configure a NAT Exemption for the /30 network.
All other options beyond this require a bit of creativity, but are probably considered non-standard, and as such should be avoided unless the solutions above don't work. If they don't, please provide specific details as to why, so we can try to provide additional solutions.