Monthly Archives: March 2013

Disable IPv6 on Linux (CentOS)

Just put this into /etc/sysctl.conf. No need to mess with the IPv6 modules.

net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1

And also inet_protocols = ipv4 in /etc/postfix/main.cf

Why would you want to do that? I have a rogue IPv6 router advertising going on in my network that I can’t block. That results in Linux boxes assigning themselves an IPv6 address from that “foreign” router. This can cause trouble when sending eMail. For example DirectAdmins exim tries to send out via IPv6 by default and if there’s no PTR set for that IP eMails might not get delivered: “550-inconsistent or no DNS PTR record for 2a01:…”. The true solution is to set a PTR, remove the rogue RA or properly enable IPv6 on own network equipment with PTRs, so this is just a dirty workaround.

PS: If postfix doesn’t start up after you disabled IPv6 and complains with the error message “fatal: parameter inet_interfaces: no local interface found for ::1” then you could remove ::1 from /etc/hosts and postfix will run again.

Receiving faxes with Asterisk, iaxmodem and HylaFax with dynamic eMail recipients

This is still the best how-to for sending and receiving faxes with Asterisk 1.4 without T.38: http://das-asterisk-buch.de/1.6/faxserver-mit-iaxmodem-und-hylafax.html – in German only, but you can probably still figure it out. I use this setup only to receive faxes and have them mailed as PDFs to the recipient. The speciality here is that the eMail address of the recipient is defined based on the called number, dynamically.

This is extensions.conf:

[fax-incoming]
exten => +496980001234,1,Dial(IAX2/iaxmodem/+496980001234)
exten => +442055446677,1,Dial(IAX2/iaxmodem/+442055446677)
exten => _0000.,1,Dial(IAX2/iaxmodem/${EXTEN})

This simply sends all incoming calls starting with 0000 to iaxmodem/called-number and faxes for the two DIDs +4969… and +4420… also to iaxmodem, passing the called number statically. The magic happens in /var/spool/hylafax/etc/FaxDispatch:

LANG=de_DE
DEST_EMAIL=$(/bin/grep $CALLID4 /etc/hylafax/emails.txt | awk ‘{print $2}’)
FEILTUEP=$(/bin/grep $CALLID4 /etc/hylafax/emails.txt | awk ‘{print $3}’)
if [ “$DEST_EMAIL” == “” ];
then

GNFAX=$(echo $CALLID4 | cut -b 1-4)
if [ “$GNFAX” = “0000” ];
then
SENDTO=$(echo $CALLID4 | sed ‘s/^0000//g’ | sed ‘s/1111/@/g’)
FILETYPE=pdf
else
SENDTO=fax-incoming@company.com
FILETYPE=pdf
fi

else
SENDTO=$DEST_EMAIL
FILETYPE=$FEILTUEP
fi

And this is /etc/hylafax/emails.txt:

+496980001234 hans@company.com pdf
+442055446677 jeff@company.com pdf

What happens is: call (fax) is coming in to +496980001234 – send it to iaxmodem/+496980001234 – pass it to HylaFax – HylaFax “FaxDispatch” script looks up in /etc/hylafax/emails.txt whether we know the called number +496980001234. If so, we also know the eMail address – hans@company.com – and the format – pdf – and HylaFax sends the received fax out to that eMail address in that format. Format can be pdf or tif. But now, if someone faxes to 0000john1111anothercompany.net then Asterisk will pass “0000john1111anothercompany.net” to iaxmodem and therefore to HylaFax “FaxDispatch”, which will do the following: if the called number was not found in /etc/hylafax/emails.txt and the called number starts with 0000, strip off 0000 and replace 1111 with the @ sign. Which translates into an useable eMail address: john@anothercompany.net. This is where the fax will be sent. If the called number does not start with 0000 and it was not found in emails.txt either, then send it to a fallback address: fax-incoming@company.com. To sum up:

1. Manage static users in /etc/hylafax/emails.txt: DID, eMail address, format of attachment
2. The eMail address of the fax recipient will be resolved dynamically for all calls that start with 0000
3. If no match in emails.txt and the called number doesn’t start with 0000, send the fax to a fallback eMail address.

Routing public IPs to a LAN behind a dynamic IP connection with OpenVPN and ipfw policy-based routing

I’ve just had the need to route a range of public IP addresses to the LAN behind my home connection (dynamic IP). Tried gre at first but couldn’t get my crappy 20 EUR home router to pass gre packets. So, gave OpenVPN a try, with success:

Data center router: route packets for 217.172.172.0/26 to 217.172.1.1

Linux box (217.172.1.1) in data center acting as OpenVPN server. server.conf:

# push “redirect-gateway def1 bypass-dhcp”
server 10.10.10.0 255.255.255.0
route 217.172.172.0 255.255.255.192
client-config-dir /etc/openvpn/clients

We’ve commented out the redirect-gateway stuff because we do not want the OpenVPN client to send all traffic through the OpenVPN server. 10.10.10.0/24 can be any RFC range really.

/etc/openvpn/clients/DEFAULT:

iroute 217.172.172.0 255.255.255.192

This will make 217.172.172.0/26 accessible from the internet through OpenVPN.

That’s it for the server side. netstat -nr looks like this:

Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
10.10.10.2      0.0.0.0         255.255.255.255 UH        0 0          0 tun0
217.172.172.0    10.10.10.2      255.255.255.192 UG        0 0          0 tun0
10.10.10.0      10.10.10.2      255.255.255.0   UG        0 0          0 tun0

Client (FreeBSD) at home:

em0:
192.168.1.2: For connectivity to home router
217.172.172.1/26: one public IP address

No special configuration needed. Just start the OpenVPN client and the server will push the important stuff to the client. netstat -nr after client is up and running:

Destination Gateway Flags Refs Use Netif Expire
default            192.168.1.1        UGS     16570 911365865    em0
10.10.10.1/32      10.10.10.5         UGS         0        0   tun0
10.10.10.5         link#23            UH         39       41   tun0
10.10.10.6         link#23            UHS         0        0    lo0
217.172.172.0/26    link#1             U           0      331    em0
217.172.172.1       link#1             UHS         0        1    lo0

192.168.1.1 = internet gateway (home broadband router)

Now all that is left is to tell ipfw to route packets which have a source address in 217.172.172.x/26 via the OpenVPN link, namely 10.10.10.5:

ipfw 10 add fwd 10.10.10.5 ip from 217.172.172.0/26 to any

And that’s it. Finally you can configure machines in your LAN with IPs from 217.172.172.x/26 with gateway 217.172.172.1 and they’ll be fully accessible from the internet. Traffic from the machines to the internet will get routed through OpenVPN.

Upgrading Juniper RE-5.0 (RE-400) to SSD

There’s a recommendation at Juniper clue on which SSD to use when replacing the traditional notebook-grade 2,5″ PATA HDD in your routing engine. The recommended Transcend 8 GB SSD is a bit outdated and was hard to find, so I gave the following Transcend 32 GB (model TS32GPSD320) a try: Amazon link.

Well, the most important thing is: the drive works fine! However, due to some tiny design flaw in the range of millimeters the result looks like this:

230320131686

That means you can’t tighten the SSD to the RE and it will be sitting there half in the air. Anyways, it does work. :-)

 

Juniper RE-5.0 (RE-400) CompactFlash upgrade

UPDATE 17th April 2013: Transcend 2 GB MLC works fine as well. Amazon link.

Juniper clue tells us the following:

“The RE5 can be easily upgraded. The CF is in a hotswap socket on top of the board and can be changed easily. SanDisk SDCJF-2048 (Standard CF) are confirmed to work with RE5.0. Transcend Industrial CF Ultra TS1GCF100I (1GB) are confirmed to work with RE5.0. The CF card may need to be zeroed out before use.”

Since a 2 GB CF was kinda hard to find these days I purchased a SanDisk Ultra 4 GB CF instead (model no. SDCFH-004G-U46) – Amazon link. The CF will get detected fine by JunOS and copying everything over from the harddrive via ‘request system snapshot partition’ works as well. The only problem is that the router will remove the CF from the boot list every time you boot up, effectively making it pointless to have a CF card installed. :-)  The reason is:

ad0: FAILURE – READ status=51<READY,DSC,ERROR> error=10<NID_NOT_FOUND> LBA=7813119

Basically this is just a cosmetic error, but the router doesn’t recognize it as such and thinks your CF is broken, which it isn’t. You will probably also see:

ad0: FAILURE – SETFEATURES 0x85 status=41<READY,ERROR> error=4

Which is ok and doesn’t cause the CF to get removed from the boot list. You can find a good explanation of both errors here. Anyway, I ended up using a SanDisk Ultra 2 GB as recommended: Amazon link. Not sure if 4 GB CFs won’t work at all in the RE-5.0 or just this particular SanDisk model. An indication that only the SanDisk 4 GB causes trouble could be that when you google for the above NID_NOT_FOUND error only the SanDisk 4 GB model is being mentioned in several mailing lists posts etc.