Cannot NAT trough OPT1 interface on multiwan

mattbunce

Unfortunately, this still doesn't seem to be working for me. I've tried used the automatically generated linked rule and manually creating a floating rule, but nomatter what I try it is still not working for me on the October 16th 09:56:37 version.

Is there anything else I should be looking at?

phil.davis

@mattbunce:

Unfortunately, this still doesn't seem to be working for me. I've tried used the automatically generated linked rule and manually creating a floating rule, but nomatter what I try it is still not working for me on the October 16th 09:56:37 version.

Is there anything else I should be looking at?

Follow the bug report also: https://redmine.pfsense.org/issues/3760
On that, cmb indicates he has done some testing and it is still not fixed.

mattbunce

Cheers Phil

I have already commented on the bug report too, I just didn't want to get too 'chatty' on there, because it seems the folks on there have done some pretty advanced diagnostics and I didn't want to distract from the good work they were doing :)

eri--

Another round of fixes.
Next snapshot should have the missing piece for fixing this.

mattbunce

I still can't seem to get this working on the 17th October, 11:27:45 version.

Have you had a chance to try it out ermal? Perhaps I am not configuring the Nat and Rules pages correctly?

M

mikeisfly

This is not working for me and I'm using 2.2-BETA (amd64) built on Fri Oct 17 20:02:23 CDT 2014 FreeBSD 10.1-RC2

I have attached my LAN, NAT (Port Forwrd), Manual Outbound NAT Rules.

I have also captured packets on both my WAN, WAN2 and LAN interfaces. On my WAN2 and LAN I can see the Syn, and the Syn Ack packets however I don't see the ack packet. Also there are some retransmissions. When I capture packets on my WAN and filter for port 32400 the capture is blank which tells me that the packet is not being sent out the default gateway. I have attached the .pcap files here in the form of a .txt file if you would like to look at them in wireshark the extension just needs to be changed back to .pcap . Hope this helps

Thanks,

P.S. Not sure why I was trying to embed these images from my onedrive folder but it didn't seem to work so I had to add attachments.

![LAN Rule.png](/public/imported_attachments/1/LAN Rule.png)
![LAN Rule.png_thumb](/public/imported_attachments/1/LAN Rule.png_thumb)
![Nat Port forward.png](/public/imported_attachments/1/Nat Port forward.png)
![Nat Port forward.png_thumb](/public/imported_attachments/1/Nat Port forward.png_thumb)
![outbound Nat.png](/public/imported_attachments/1/outbound Nat.png)
![outbound Nat.png_thumb](/public/imported_attachments/1/outbound Nat.png_thumb)
[capture on LAN.txt](/public/imported_attachments/1/capture on LAN.txt)
[capture on wan2.txt](/public/imported_attachments/1/capture on wan2.txt)

Wolf666

I think my problem is the same.
If someone has some spare time to read: https://forum.pfsense.org/index.php?topic=82944.0

I am running:

Version 2.2-BETA (amd64)
built on Fri Oct 17 20:02:23 CDT 2014
FreeBSD 10.1-RC2

I am available to test any solution and report back.

mikeisfly

It's a known bug and the developers are working on it. Until then if this is a deal breaker you can try going back to 2.1.5 until the issue is resolved. That is what I'm doing.

stewgoin

I'm seeing the same issues on the current snapshot – I've worked around the issue with some sourcerouting and having an upstream system on one of the WAN links handle NATting for now. That works (firewall rules forcing a gateway, then having manual NAT rules disabling NAT).

It looked like using firewall rules to force the alternate gateway would make the multiWAN NAT rules start working correctly, but I didn't test that yet. It definitely adds another layer of config management to do this, so I eagerly await having this one squished :)

cmb

Don't change anything on your system trying to fix this, it's part of the packet filter that's currently broken in snapshots. It's slightly more correct now, as reply-to does at least return route correctly. But it's sending traffic with broken checksums, which still leaves it broken. Ermal's heading home from our hackathon in a few hours. He'll fix that when he gets back home later in the week.

stewgoin

@cmb:

Don't change anything on your system trying to fix this, it's part of the packet filter that's currently broken in snapshots. It's slightly more correct now, as reply-to does at least return route correctly. But it's sending traffic with broken checksums, which still leaves it broken. Ermal's heading home from our hackathon in a few hours. He'll fix that when he gets back home later in the week.

It's just a little portion of the old home network, and thankfully the changes are easy backed out to test any fixes :)

Thanks a ton for the feedback that it's being worked on, aside from this particular snag, 2.2 is looking stellar for my usage.

mattbunce

@stewgoin:

Thanks a ton for the feedback that it's being worked on, aside from this particular snag, 2.2 is looking stellar for my usage.

Agreed - I'm new to pfSense, but I'm very impressed with the speed of development and the "get it right in the GUI" approach. I've been using OpenWRT for a few years and there is a real tendency to push any advanced configuration to the command line, leaving much of your intricate configuration hidden within the GUI. I think the approach pfSense takes seems much more sensible - right down for the meaningful descriptions of all parameters in within the GUI

mattbunce

@cmb:

Ermal's heading home from our hackathon in a few hours. He'll fix that when he gets back home later in the week.

Hi Ermal - have yo had a chance to take a look at this yet?

M

eri--

Please test next coming snapshot.

cmb

This works for me on IPv4 now with a kernel Ermal built with the fix that'll be in the next round of snapshots. Hopefully next snapshot run will be good (first one from the 30th should have it).

mattbunce

Thanks Ermal - Everything seems to be working great now :)

cmb

IPv4 is fixed here, still an issue with IPv6 and TCP but all the common cases confirmed working with today's snapshot.

FisherKing

IP4 is working for me now also. Thank you!

athurdent

@cmb:

IPv4 is fixed here, still an issue with IPv6 and TCP but all the common cases confirmed working with today's snapshot.

I can confirm the issue with IPv6, but ICMP does not seem to work in my case. The rule below used to work on my 2.1 install. I have migrated my old config to a 2.2 test machine.

Screenshot.png_thumb

cmb

@athurdent:

I can confirm the issue with IPv6, but ICMP does not seem to work in my case. The rule below used to work on my 2.1 install. I have migrated my old config to a 2.2 test machine.

That's route-to, not reply-to. I'll check that, I'm not aware of any issues there, but that type of scenario isn't as widely used with v6 as with v4.