It look like I found a solution, if anyone else has that problem at a later time this is it:

"With modern 2.4.x Linux systems, most users point their finger at the adminstrators of these remote
broken sites (typically SSL-encrypted WWW sites, etc.) or your MASQ server's upstream router run by
your ISP. The main though it that these machines are either filtering or not properly responding to SOME
or ALL FORMS of ICMP packets (specifically ICMP Code 3 Type 4 - Fragmentation Needed) messages
due to a fray of misplaced security paranoia.
What does that all mean? Basically, say your machine is connected to the Internet with a MTU of 1492
bytes (Maximum Transmission Unit -- the maximum packet size your computer can transmit) which is
common for PPPoE users. At the same time, the remote WWW/FTP site is connected to the Internet at a
MTU of 1500 bytes. The way that TCP/IP works is that when a TCP connection is being negotiated for
your HTTP / FTP connection, the remote side will try to verify that a 1500 byte packet can reach your
computer via the initial TCP "SYN" packet.
Since the packet is too big for your connection, your upstream router (run by your ISP) will send a ICMP
3:4 (fragmentation needed) packet back to the remote WWW / FTP server. Within this packet is a
recommended smaller MTU size to retry with. The problem is that either your local upstream router, some
router between you and the remote server, or the remote HTTP / FTP server is either misconfigured or
has a firewall in front of it that is BLOCKing these ICMP packets.
The final UNCOMMON possibility is a debatable 2.0 / 2.2 kernel bug in the IPMASQ code. Some users
point their finger to the fact that IPMASQ might have problems with ICMP packets that have the DF or
"Don't Fragment" bit set. Basically, when a MASQ box connects to the Internet with an MTU of anything
less than 1500, some packets will have the DF field set. Though changing the MTU of the MASQ server's
Internet link to 1500 seemingly fixes the problem, the possible bug is still there. What is believed to be
happening in these older kernels is that the MASQ code is not properly re-writing the return IP addresses
of the ICMP 3 Sub 4 code packets back to the originating MASQed computer. Because of this, these
critical packets get dropped."
We thank David A. Ranch for the explanation on ibiblio.org.
For me setting the MTU to 1500 on the outbound interface didn't work, I had to use clamp mss to pmtu,
running the command I have written in the previous comment.
You need to insert that command in the /config/scripts/vyatta-postconfig-bootup.script so that it remains
active after reboot.

LaurianLamba