Routing GRE packets through Pepwave Max

I’m using a Pepwave Max Transit running 7.0.0 with a Verizon Wireless SIM card. The LAN side is connected to two cisco routers through an intermediate switch.

The cisco routers are configured with gre multi-point tunnels that route traffic through the Pepwave. I haven’t been able to make the tunnels work, though other (non-gre) connectivity through the Pepwave seems to be functioning. For example, I can ping (icmp), traceroute (udp) and even telnet through the Pepwave to distant sites via Verizon Wireless.

Verizon dhcp-assigns the Pepwave an ip address in shared space ( and performs Carrier Grade NAT translating that into a routeable address at the far end.

However, as far as I can tell, no GRE packets are getting through.

Is this a limitation of the Pepwave software, or is there some way of accomplishing what I’m trying to do?

At this point, I’d be willing to reduce the scope of the job to using a single cisco router, if that makes the difference (e.g., by specifying it as the target of all incoming gre packets, or even of all packets from specific distant tunnel endpoint ip addresses).

I did a first level search of the archives here, but mostly people seemed to be discussing the experimental feature where the Pepwave router itself implements a gre tunnel. This is not what I’m trying to do. I’m just trying to get it to route gre packets.

As an aside, I assume that the existing experimental gre tunnel feature can’t be used in my environment given Verizon’s use of carrier-grade NAT. If I’m wrong about this, please let me know.

Just to confirm are you looking at GRE tunneling between the Cisco switches through the cellular network?


Thanks - Bob

For GRE tunneling between the Cisco Routers, i believe you need to have the two ways communication connections for the Cisco routers.

Cisco router 1 — reachable–> Remote Cisco Router
Remote Cisco router —reachable-> Cisco Router 1

Seem connection for Cisco router 1 is NATed by the ISP, don’t think Cisco Router can established GRE tunnel for such setup.

For more information, please refer to the URL below;

This is definitely not related to the PepWave device and it’s more to the minimum requirement for the GRE tunnel to establish.

Do consider the design below to overcome the connection requirement for the Cisco GRE tunneling:

  1. Build PepVPN/SpeedFusion between the MAX Transit with the Center Balance/MAX router (Make sure Public IP is available for Centre Balance/MAX)

  2. Establish the GRE tunneling through the PepVPN/SpeedFusion between the Cisco Router.

Thank you for your suggestion, it doesn’t fit with our application.

Our typical customer has some sort of leased-line connection back to our network plus a fall-back path. The typical fall-back path is a connection to a multi-point tunnel over DSL/CableModem/FiOS back to routers at multiple or our POPs.

We are looking to use the Pepwave MAX as a device we could take to a customer site experiencing an outage where all the other paths in were broken, e.g., due to a manhole fiber outside the building. Deploying additional Peplink equipment at multiple POPs was not part of our plan.

We have quite a bit of experience configuring cisco multi-point gre tunnels, including cases where there is a separate NAT-ing device at the customer site, such as a cable-company provided low-end consumer-grade wifi router.

Even in those cases, we can generally get things working by specifying the ip address of a customer-site cisco router as the DMZ, the target of all incoming packets that are not otherwise routed, e.g., by entries in the NAT table.

Is there a similar configuration option on the Pepwave MAX?

The above was the only problem I’d anticipated.

I mentioned Verizon’s use of “Carrier Grade NAT” because I was seeing a different (additional?) symptom in the logs of our central-site cisco routers.

On the plus side, basic udp and tcp communications through the Verizon wireless network worked. We could telnet from the remote site cisco router to the central site cisco. At the central site udp and tcp packets arrived with the source ip address NAT’d to an ip address in a block allocated to Verizon (again, as expected).

However, gre packets sent from the remote site arrived at the central site with an unexpected ip address. Specifically, they arrived with the source address of the cisco router, the source address that was on the packet when it went from the cisco router to the Peplink.

The symptoms are as if the Peplink MAX is not NAT-ing the gre packets when it sends them to Verizon and as if Verizon were accepting these packets despite their unexpected (to Verizon) source address. I thought this scenario seemed pretty unlikely, and so I was worried about some sort of interaction between gre packets and Carrier-Grade NAT.

Any response to the limited question about specifying a dmz LAN ip address?

I’m not sure whether your previous experience for the GRE tunnels is on cellular network. Like you say, cellular service provider may perform “Carrier Grade NAT” tor those dynamic shared space IP ( service subscription. This actually doesn’t allow the inbound access for the device connected to such cellular network and cause a big challenge for GRE tunnels to established. To overcome the “Carrier Grade NAT” tor those dynamic shared space IP ( service subscription, most of the user have move the cellular subscription to using Static Public IP that will cause extra changes.

Some of the Pepwave MAX model support IP pass-through feature that allow the LAN direct connect device to run using Public IP assigned by the Cellular network.

Configuration guide can be found here:

Last but not least, i would suggest you to read on the white paper below for the technology that you may consider to improve the site to site connections.

Consistent with your suggestions, I upgraded our Verizon Wireless account to support static ip addresses and, as you wrote, that should eliminate any concerns related to CGN. I hope my remaining problems can be solved with simple configuration changes on the Pepwave Max router.

I have enabled logging on the remote tunnel-target cisco router and, while I can verify the arrival of icmp, udp and tcp packets, I can not see that any gre packets are arriving.

It’s clear that the Pepwave Max is applying outgoing NAT correctly when it sends icmp, udp and tcp packets. Is it possible that it is NOT translating the source ip address on gre packets being sent out via cellular? It’s understandable that Verizon would drop such packets. If this is the case, is there a way for me to configure the Pepwave Max so it will NAT the outgoing packets?

Independently, with regard to cellular incoming traffic, what is the suggested configuration so that gre packets are delivered to the right LAN system? It looks like I can configure a “Port Forwarding” rule that would match all GRE packets (IP protocol number 47). Is this the right place for me to be looking?

Possibly there is no way for the current Pepwave software to handle gre packets between the LAN and wireless ports.

If this is the case, can anyone recommend another product that would meet this requirement?

There certainly are multiple levels of “gre support” that would be acceptable.

It’d be great if the router exhibited some level of gre awareness but, at a minimum, we’d accept:

(1) gre packets being passed to the wireless link get NAT’d to the pepwave router’s wireless-facing address, just like other ip packets.

(2) gre packets arriving from the wireless link get delivered to some inside system, even if this is only a system specified in the router’s configuration as the target of all incoming gre packets.

Are you referring Wireless port as Cellular connection or WIFI WAN or WIFI AP ?

My apologies. I meant cellular. We have the wireless function disabled.

Not sure i understand you correctly.

Are you looking at outbound NAT & Inbound NAT ?

Outbound NAT:
Default all traffics passed from LAN to WAN will be NAT’d (WAN IP)

In case you don’t want the NAT you can enable “IP Forwarding”

If you found the GRE traffics is not NAT’ed, Please open a support ticket for the team to check here. This is not a expected behavior.

Inbound NAT:
Please refer to the forum thread below:

I will open a support ticket when I’m back at the office and have access to the device serial number.