Cannot NAT trough OPT1 interface on multiwan
-
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 :)
-
Another round of fixes.
Next snapshot should have the missing piece for fixing this. -
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
-
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.
[capture on LAN.txt](/public/imported_attachments/1/capture on LAN.txt)
[capture on wan2.txt](/public/imported_attachments/1/capture on wan2.txt) -
I think my problem is the same.
If someone has some spare time to read: https://forum.pfsense.org/index.php?topic=82944.0I am running:
Version 2.2-BETA (amd64)
built on Fri Oct 17 20:02:23 CDT 2014
FreeBSD 10.1-RC2I am available to test any solution and report back.
-
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.
-
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 :)
-
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.
-
@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.
-
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
-
@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
-
Please test next coming snapshot.
-
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).
-
Thanks Ermal - Everything seems to be working great now :)
-
IPv4 is fixed here, still an issue with IPv6 and TCP but all the common cases confirmed working with today's snapshot.
-
IP4 is working for me now also. Thank you!
-
@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.
-
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.
-
Ah, sorry, I have set this up a long time ago and forgot to mention that there actually is NAT involved. The setup is a workaround to be able to use 2 IPv6 gateways described here:
https://forum.pfsense.org/index.php?topic=71293.msg402861#msg402861
But it was working OK on 2.1. ;) Anyway, thanks for looking into this and if someone has a better idea, feel free to revive that old thread. -
Just another testimonial over here. WAN2 working fine now. I'm not using IPv6 as of yet but will deploy to track development PfSense 2.2 Beta. I'm currently running the snapshot dated Nov 1 64bit.