Cannot NAT trough OPT1 interface on multiwan

mattbunce · Oct 16, 2014, 7:40 PM

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 · Oct 17, 2014, 12:38 AM

@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 · Oct 17, 2014, 7:40 AM

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-- · Oct 17, 2014, 4:33 PM

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

mattbunce · Oct 18, 2014, 12:27 AM

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 · Oct 18, 2014, 2:17 PM

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 · Oct 18, 2014, 9:24 PM

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 · Oct 18, 2014, 10:21 PM

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 · Oct 19, 2014, 2:56 AM

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 · Oct 19, 2014, 8:28 AM

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 · Oct 19, 2014, 6:23 PM

@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 · Oct 19, 2014, 9:31 PM

@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 · Oct 24, 2014, 1:11 AM

@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-- · Oct 29, 2014, 10:24 PM

Please test next coming snapshot.

cmb · Oct 29, 2014, 11:50 PM

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 · Oct 30, 2014, 2:24 PM

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

cmb · Oct 30, 2014, 7:18 PM

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

FisherKing · Oct 31, 2014, 5:24 AM

IP4 is working for me now also. Thank you!

athurdent · Oct 31, 2014, 1:53 PM

@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.

cmb · Oct 31, 2014, 9:43 PM

@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.