VMware Communities
rcardona2k
Immortal
Immortal

PPTP VPN not connecting through Fusion NAT

I've installed a VPN Client that requires standard PPTP TCP port 1723 and IP Protocol 47 to be forwarded. Is there a NAT config for forwarding generic IP prototype types?

btw, I've disable the Windows XP firewall to be sure all ports are open on the client-side.

Reply
0 Kudos
18 Replies
Harliv
Hot Shot
Hot Shot

you can edit nat.conf just like in Workstation. The file is located in:

/Library/Application Support/VMware Fusion/

Harliv
Hot Shot
Hot Shot

You will need to restart the vmnat process after editing the file.

Reply
0 Kudos
rcardona2k
Immortal
Immortal

Thanks - I've been editing nat.conf with no luck and restarting with boot.sh.

I can port forward TCP port 1723 but I don't see anything for generic IP protocols like 47 (General Routing Encapsulation). For instance TCP is protocol 6 and UDP is protocol 17. I have a feeling there's no way to tunnel an entire IP protocol like 47 through.

Reply
0 Kudos
Harliv
Hot Shot
Hot Shot

That is possible. I only verified that tcp forwarding works. I don't believe that generic IP type forwarding is normally available in Linux or BSD NAT either, but I could be mistaken.

Reply
0 Kudos
bgertzfield
Commander
Commander

Hi rcardona,

If this isn't working with NAT with the public beta, please file a Support Request. Thanks!

Reply
0 Kudos
rcardona2k
Immortal
Immortal

OK, will do! I'm compiling a list of issues I've run across and I plan to verify each one, collect the proper logs and open appropriate SRs.

Right now, I'm just basking in the warmth of this new public beta.

Reply
0 Kudos
bgertzfield
Commander
Commander

Excellent. Happy holidays! I hope you enjoy the present of Fusion's public beta. Smiley Happy

Reply
0 Kudos
admin
Immortal
Immortal

GRE forwarding doesn't require any special configuration in nat.conf. It should just work out of the box.

If it doesn't on Mac OS (certainly possible, because Mac OS is a different beast from Windows and Linux), then it is a bug.

As BenG suggests, please file an SR against it.

Thanks for finding this issue! It will help make the product more solid by the time it is GA!

Reply
0 Kudos
rcardona2k
Immortal
Immortal

FWIW, this issue is now filed as Support Request SR# 345988

Reply
0 Kudos
admin
Immortal
Immortal

Hi rcardona2k,

We are unable to reproduce this inhouse with a Cisco VPN client in a Windows XP VM.

Can you tell us which VPN client you're using? Also, if it has any sort of verbose/debug logging you can turn on in the VPN client, and send them to us, that would be tremendously helpful. An ethereal/wireshark sniffer trace in the Windows VM while the VPN connection fails would be awesome too!

Thanks!

Reply
0 Kudos
rcardona2k
Immortal
Immortal

Thanks for looking at this. Could the difference be that I'm using the e1000 virtual NIC?

I can't reveal the VPN client publicly but let me capture the logs of a successful connection via bridged + Apple NAT, vs. Fusion NAT and I'll attach them the SR above. Do you have quick access to SR attachments when I add them?

Reply
0 Kudos
rcardona2k
Immortal
Immortal

I'm having trouble exporting the capture .pcap out of Ethereal as text. I have to remove our VPN server's name, IP, and payloads so I can't send you binary captures. I can send you packet header descriptions. The VPN logs are not helpful, they are too high-level, e.g. "connection failed"

The difference i'm seeing at a high level, is in the GRE PPP Link Control negotiation, with Fusion NAT, there's a repeating, stalled set of these packets:

"PPP LC Configuration Request"

IPv4, Protocol: GRE (0x2f), Flags: 0, TTL 128

Protocol: GRE, protocol and version: 0x3001, prototype type: 0x880b

PPP Protocol: Link Control Protocol, 0xc021

PPP Link Control Protocol: Configuration Request, Code: 0x01

In the working, bridged case, the response is a PPC LC Configuration ACK,

"PPP LC Configuration Ack"

IPv4, Protocol: GRE (0x2f), Flags: 0, TTL 128

Protocol: GRE, protocol and version: 0x3001, prototype type: 0x880b

PPP Protocol: Link Control Protocol, 0xc021

PPP Link Control Protocol: Configuration Request, Code: 0x02

I've been to a few Wi-Fi hotspots that don't allow GRE to pass and Fusion NAT acts exactly the same way.

Reply
0 Kudos
admin
Immortal
Immortal

Thank you!

This is pretty helpful. Yes I do have access to SRs, so feel free to upload any sanitized files there if you can.

Reply
0 Kudos
rcardona2k
Immortal
Immortal

I decided to export to tcpdump format whose command line options I know how to use. (Or I guess I can try to figure out ethereal on the command line). Once I have the packet stream in text, I can clear out the sensitive stuff and attach the log to the SR. It will take me some time to do this, hopefully by later today.

Reply
0 Kudos
rcardona2k
Immortal
Immortal

The Ethereal/tcpdump traces have been appended to VMware Support Request SR# 345988

Reply
0 Kudos
rcardona2k
Immortal
Immortal

This issue is resolved now. I have sent in a "Close" SR response. Thanks for your quick turnaround on my network traces.

Reply
0 Kudos
blackpearl
Contributor
Contributor

How do you edit the nat.conf files in order to connect VPN through Fusion NAT

Reply
0 Kudos
asatoran
Immortal
Immortal

How do you edit the nat.conf files in order to connect VPN through Fusion NAT

Use a text editor like TextEdit to open vmnet-nat.conf. Take a look at the sections and . But if you're trying to port forward PPtP, dont bother. AFAIK, VMWare NAT does not pass the needed GRE protocol. So PPtP only works with bridged, not NAT.

Reply
0 Kudos